Simulink/C2000 Piccolo target: I2C communication fails when running continuously

Hello!

I am using the Embedded Coder Support package for TI's C2000 Processors in combination with a F28069 board (Launchpad XL). My goal is to use the STM LSM9DS0 inertial measurement sensor over the I2C interface. I have made a very simple program that in each time step reads out the ID of the (separate) accelerometer and gyroscope on the sensor. I sorted the execution of the write and read blocks via Function-Calls. When I run it on the board in normal mode I can see that signals are sent over the clock and data line in my oscilloscope. But the returned data is wrong.

Now when I run the same program step by step in the Code Composer Debugger it works perfectly.

After looking at the generated code and halting the program in the debugger it appears that the I2C transmit FIFO (I2caRegs.I2CFFTX.bit.TXFFST) stays filled with one byte when running "continuously". This seems weird to me as the generated code already incorporates a loop that waits some time for the transmit action to finish.

    {
      int unsigned tx_loop= 0;
      while (I2caRegs.I2CFFTX.bit.TXFFST!=0 && tx_loop<10000 )
        tx_loop++;
      if (tx_loop!=10000) {
        I2caRegs.I2CSAR = 107;         /* Set slave address*/
        I2caRegs.I2CCNT= 1;            /* Set data length */

        /* mode:1 (1:master 0:slave)  Addressing mode:0 (1:10-bit 0:7-bit)
           free data mode:0 (1:enbaled 0:disabled) digital loopback mode:0 (1:enabled 0:disabled)
           bit count:0 (0:8bit) stop condition:0 (1:enabled 0: disabled)*/
        I2caRegs.I2CMDR.all = 26144;
        tx_loop= 0;
        while (I2caRegs.I2CFFTX.bit.TXFFST==16 && tx_loop<10000)
          tx_loop++;
        if (tx_loop!=10000) {
          I2caRegs.I2CDXR = (uint8_T)i2c_test_P.Constant_Value;
        }
      }
    }

The same problem persists when I distribute the write and read actions over separate time steps. I can only get it to work when executing the code step-by-step in the debugger. Maybe you know of some common mistake that I made or some workaround that would help me.

Thank you for your help!

Answer 1

[Jijing Yan]

Hello, I have also the same problem. Have you perhaps solved it? Could you please give mes some hints? Thank you very much.

[offroad]

I did find a workaround for the problem upon closely inspecting the source code. To me it seems that the I2C interface generates code that cannot work continuously. In the "c280xi2c_tx.tlc" file of the toolbox there are several lines where the code checks whether the device is busy and will wait if so. The code is always some variation of the following:

while (I2caRegs.I2CFFTX.bit.TXFFST!=0 && tx_loop<10000 )tx_loop++;

So it checks whether the device buffer has not been fully emptied yet. I could solve the problem when I replaced the respective lines by:

while((I2caRegs.I2CMDR.bit.STP == 1) || (I2caRegs.I2CSTR.bit.BB == 1));

This code will check whether a stop bit is set or whether the bus is still busy. If so it will wait. This way the communication works continuously. I am not sure why the original I2C implementation does not explicitly check whether the bus is still busy before writing on it. It seems that the bus consequently enters an inconsistent state and does not recover.

So in conclusion I do think that this represents a bug in the toolbox that Mathworks should fix.