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.

Need help with recovering I2C0 bus in TMS320C6713

Hi,

I am working on a device that has a TMS320C6713 talking with two slaves (one RTC and one Temp sensor) via I2C. The unit is randomly locking up. With some troubleshooting I have narrowed down the issue to be with the I2C bus. It appears that the bus is getting locked-up once in a while and the DSP is not able to recover even after resetting the I2C interface numerous times.

After doing some search I found that during such lock-ups, it is usually the slave that is keeping the bus busy. I also found the data sheet for the temp sensor (LM92CIM) recommend sending 9 clock pulses and a stop bit to flush out the slave register and release the bus. However, the I2C0 of TMS320C6713 does not allow it to use as a GPIO so that I could toggle the pin and issue 9 clocks.

Please let me know if there are any workarounds to make the I2C0 of 6713 to send just 9 clocks on SCL and a stop on SDA. I did read about ‘free data format’, but am not sure if this could be used for this purpose. If free data format could be used to release the bus, any guidance / tips to implement this would be greatly appreciated.

RTOS: DSP/BIOS 5.41

CGT: 7.0.4

CCS: 4.2.3

Emulator: XDS510USB

Thanks

Joe

  • Joseph,

    Are you using the BIOS PSP? If yes, then could you please mention the BIOS PSP version?

    Thanks and Regards,

    Sandeep K

  • Hi Sandeep,

    Thanks for your reply. To answer your query, no, we are not using PSP.

    Can we configure the I2C0 of TMS320C6713 to issue 9 clock pulses followed by a stop bit? Perhaps using the free data format?

    Thanks,

    Joe

     

  • Hi Joseph,

     

    To my knowledge, during such situations - 

     

    Wherein, the slave device holds the SDA and SCL lines and the bus is busy completely(slave locks up the bus). 

    For the Master to get back the control over the bus, the slave side needs to be flushed as you mentioned.

     

    So to recover from such a situation, you need to configure the external I2C pins as a GPIO pin and toggle the pin to issue 9 clocks and send STOP. Since this facility(configuring the I2C pins as GPIO pin) is not provided in the I2C of TMS320C6713, it is not possible to recover from such a behavior except resetting the board :( 

    The free data format may not be of help since NO further transactions can be made on the bus by Master.

     

    At this point, we can only think of avoiding such a behaviour. I believe, this could be achieved by reducing the I2c bus frequency!.

    Can you please try reducing the the I2c bus frequency and check if this issue can be reduced?. This is because, some of the slave devices may not work(reliably) for higher bus frequencies. Better read/write transactions can be observed at lower frequencies.

     

    Hope this answers your questions. Do try reducing the frequency, and let me know the results..

     

    Thanks & regards,

    Raghavendra

  • Hi Raghavendra,

    Thank you for your response. I was hoping the answer would be more positive :(

    I will look into lowering the bus speed and see if it is a viable option. That being said, I would like to make the system as robust as possible due to the way the end product will be deployed. In other words, if there is a bus lock-up, I would like to recover from it without rebooting the whole system.

    I have already added code to reconfigure the I2C to free data format when the bus gets locked-up. This code is now part of an abort routine that resets the I2C interface whenever the bus gets locked. But the lock-up is so random and spaced out, I have not seen any lock-ups since last week. Therefore, at this point, I am not 100% sure if free data format would help us or not.

    Thanks for all your help and advice,

    Joe

  • As Raghavendra suspected, when the SDA is held low by a slave, configuring the TMS320C6713 to free data format as mentioned here did not help with releasing the bus. The DSP didn't appear to be able to send a start bit followed by clocks and a stop bit.