• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 919 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LM4F120H5QR I2C stucks in busy/error

Marton Ferenc Csutoras
Prodigy 40 points

Hi,

I'm working on a drone project in which I have to read out the acc/gyro data from an MPU6050 IC. I'm using I2C protocol and the device is connected to the I2C2 modul. I'm able to read/write the registers in MPU6050, but after a random amount of time after the start-up I'm not able to communicate with the IC anymore.

I tried to investigate what is the problem, but the pulls up are okay, the soldering as well. The software I think fine, since I can read/write of the registers of the MPU6050. The loss of communication happens randomly after the power-up. Originally the read operation from the MPU6050 were in a ISR routine called every 1ms (bus speed 400khz), but in order to exclude the memory corruption or any other kind of problem cause by another ISR, I've moved the code in to the begining of my program. Even in that case I had problems with communication with the IC, again after random amount of seconds after start-up.

During the investigation I've found tthe following stange things.

1.
Any case the error occures on the I2C, the stellarisware lib functions are not able to transmit any more on the I2C. Not even the slave address. It seem that the I2C modul stucks in the error state. The error bits are set. The BUSBSY and DATACK. 

2.
The stellarisware lib functions are not able to clear the BUSBSY and DATAACK bits after the reinitlaization of the I2C even after I restared the uc with the debugger. I've tired to force turn off and on the I2C module, since after the restart of the debugger the previous settings and errors were present in the I2C registers. So I've added the I2CPeripheralEnable(..)+I2CPeripheralDisable(...)+I2CMasterDisble(..)+I2CMasterEnable(...), to force turn off and on, but it didn't help. The errors still were present in the I2C2MCS register :(

3.
I've analysed the signals on the I2C. See the attached picture below.

In the green circle the written data has been acked by the MPU6050. With the signals below (in paint) there is two problems! The first, that wrong data has been transmitted, one bit is missing (ok, let's say my fault in the code), but the second, that the I2C modul transmitted only 8 CLK cycle, not 9! The last cycle's falling edge is missing! This is very odd. I would say, that there is some problem with the uc's I2C modul. Also the MPU6050 doesn't ACK the write, but is okay, since the uC didn't trasmit the last falling edge.
So after this point, the I2C modul becomes "silent", the stellarisware lib functions are called properly, still no data transmitted. Some case the code stucks in the I2C master busy wait.

+1
I've replaced the LM4F120H5QR (I'm using the starter kit) with a new one, the problem is the same.

I'm really lost. What do you think, what could be the problem? Any suggestion to try?

  • 0
    Guru 13040 points
    Hello Marton,
    Are you talking about the small Launchpad EK-LM4F120XL? If so, wouldn't you consider to move to the current product? Stellaris is no longer produced, and everything that descends from that family is now Tiva, or TM4C. The small launchpad is quite inexpensive.
    Over the past few years, there has been a lot of improvement on TivaWare, and the I2C functions on the library are quite comprehensive.
    I haven't dealt during the Stellaris time, but there are different configurations on the I2C parameters as to add or not one last bit (which is roughly used to signal the existence of one extra flow of bits on the communication or to indicate the end of that transfer). If the old library has that as well, maybe you are using the wrong settings?
    Take a look at the User Guide of the most recent TIvaware library, on the I2C part, and you will see it's not too hard to understand the transmission parameters and options...
    Or if you are patient enough or get no other reply, can you try to do a bit-bang communication routine controlling GPIO's instead of using the peripheral, and see if it works well? Not great for controlling a drone, but well, neither is to use a discountinued MCU.
    Regards
    Bruno
  • 0
    TI__Guru**** 244400 points
    Hello Marton,

    I agree with Bruno. LM4F devices are not in production, so you would need to use a TM4C equivalent device.

    There are some advantages to using TM4C123x device. First of all a glitch filter has been implemented which can help with glitches on both SCL and SDA lines. I can see that you are capturing using a Logic Analyzer. What is the threshold for the LA set as?

    Secondly, when restarting the uC, using the debugger use the System Reset and not CPU reset. The former will help clear the I2C status. Second of all when enabling the I2C always perform

    SysCtlPeripheralDisable(SYSCTL_PERIPH_I2C2C):
    SysCtlPeripheralReset(SYSCTL_PERIPH_I2C2C):
    SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C2C):

    while(!(SysCtlPeripheralReady(SYSCTL_PERIPH_I2C2C)))
    {
    }

    This will clear the I2C module status bits.
  • 0 in reply to Amit Ashara
    Prodigy 40 points
    Hello Amit,

    the threshold of the LA is fixed to 1.2V.

    I've added the SysCtlPeripheralReset to my code, now the error bits are cleard. Thank you for the hint! I'll add this for the rest of my code.

    Unfortunelty the problem with the I2C is still present. I've got the same error like on the picture, the 9th CLK cycle is missing from the transmission. Any guess why the I2C modul could fail with 9th cycle?

    Regards,
    Marton
  • 0 in reply to Marton Ferenc Csutoras
    TI__Guru**** 244400 points
    Hello Marton,

    I believe there is a glitch on the I2C SCL line that the LA is not able to capture due to its sampling rate. Such glitches can be easily seen on a oscilloscope of 500MHz bandwidth. As I mentioned earlier, the LM4F devices do not have glitch filter which the TM4C devices have. So I would be advise you to

    (a) Switch to a TM4C part or (b) try to find the cause of the glitch and eliminate the same.