TMS320F28035: Read and write operation using EEPROM through I2C

Hi Felipe,

For the issue you're seeing you say it gets stuck in the read function, so it never returns? Can you see where it gets stuck while debugging? You might need to turn off FREE mode using the I2CMDR register within your read function to successfully debug. Are you not seeing anything on the scope after the write function? Might help in debugging to check the I2CSTR (status register) within the expressions window of ccs after the write function and at different points of your read function.

For your write then read test, are you performing the following?

        Error = I2CA_WriteData(&I2cMsgOut1);

        Error = I2CA_ReadData(&I2cMsgIn1);

Best,

Kevin

Hello Kevin,

Thank you for replying me.

Yes, I am performing the above procedure to write and read.

Watchig I2C register, when trying to read, the I2C status register content is 0x0410. According to the datasheet, this register value means there is no underflow detected, at the same time the data has been copied from I2CDXR to I2CXSR. Assuming the I2C is not under reset condition, does it mean it is waiting another load to I2CDXR register?

Best regards,

Felipe.

Hi Felipe,

So the only difference is the NACK sent bit. Should have mentioned this earlier, but it'd be useful to check the value of the I2CMDR register before & after reading for both cases (I.E. after writing and when only reading). Maybe the bus is busy?

I2caRegs.I2CSTR.bit.BB == 1

In your code the read/write functions return errors, but there is no error checking within the main loop. Are there any errors occurring within the read/write functions? Are there any waveforms you can see when performing a read after writing? I probably need to run the example program again and look at the resulting waveforms, but I believe you have to attempt reading the EEPROM address multiple times before succeeding while you only have one attempt occurring.

Best,

Kevin

Hello Kevin,

After some tests, popably the bus is busy as you mencioned. I changed the code a little bit, and, putting some breakpoints at the main function (after writing and after readind functions), and I was able to see both waveforms perfectly, exactly as expected. But, if I remove the breakpoints, the code just write, like before. It seems there is some flag or status preventing the correctly bus function.

So, I did a delay function, which needs some adjustment, in put it before ending both write and read functions. It is not an elegant  approach, but is working. I am not sure if in the final project I need this task (writng and reading in sequence), but, at least I have this option.

Do you need is there a better approach?

I also attached the new code.

Greetings,

Felipe.

BMS_v3.rar

Hi Felipe,

Yes, it's likely that the initial write communication is not yet completed and the I2C peripheral is getting confused. I'd suggest looking at how the Example_2803xI2C_eeprom example program within C2000Ware handles its communication using the CurrentMsgPtr->MsgStatus.

Your read function is probably producing an error somewhere within it. You should probably implement some sort of error checking/handling code. I could see one of the two checks below triggering:

    //
    // Wait until STP bit is cleared from any previous master communication.
    // Clearing of this bit by the module is delayed until after the SCD bit is
    // set. If this bit is not checked prior to initiating a new message, the
    // I2C could get confused.
    //
    if (I2caRegs.I2CMDR.bit.STP == 1)
    {
      return I2C_STP_NOT_READY_ERROR;
    }

    //
    // Check if bus busy
    //
    if (I2caRegs.I2CSTR.bit.BB == 1)
    {
        return I2C_BUS_BUSY_ERROR;
    }

Hope this helps,

Kevin

Hello Kevin,

I followed your sugestion, and I got the waveform below. In order to verify if the write time is correct (ate least, in the same order of magnitude), I read the memory datasheet and found the maximum write time cycle is 5 ms, which is in agreement with the waveform. Do you believe this assuption is correct?

As we can see, the controller writes the data, and tries to read it back. It tries several times before it gets it back. After that, it verifies if the recovered data is equal to the sent one. If it is, it stops the programm using the pass() function. I read the firmware and looked for some document, but I am not sure if it is what is expected. Do you know if this is the correct firmware function?

If it is correct, the next step is to use it for another device.

Thank you for all the support.