Telecominfraproject
Bug: No timeout for I2C_MODE_BLOCKING
Product: (OC-SDR, OC-LTE, OC-LTE, OC-Power, others)
OC-SDR
Component: (PSU, GBC, BBU, FEM, LED, ME)
GBC/PSU/SDR/FE/SYNC
Category: (Hardware, Software/stack, Firmware/bootloader, Documentation)
Firmware/OCWare Describe the issue found Currently, I2C is implemented as I2C_MODE_BLOCKING and do not have any timeout!. This is known issues with TI-RTOS (See: https://e2e.ti.com/support/embedded/tirtos/f/355/t/490300)
Alternate to this is have I2C transaction as non-blocking, by changing the I2C mode to be I2C_MODE_CALLBACK, and have proper callback handling. Note the I2C_Transaction will persists until the transfer function is completed.
Defaults values are: transferMode = I2C_MODE_BLOCKING transferCallbackFxn = NULL bitRate = I2C_100kHz
See I2C_transfer documentation at: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/tirtos/2_20_00_06/exports/tirtos_full_2_20_00_06/products/tidrivers_full_2_20_00_08/docs/doxygen/html/_i2_c_8h.html#ae1aa99e1fee4517406018e10025cca0e Please provide all necessary steps to reproduce the issue
[Originally commented by @markhor ] I2C_Params documentation used during I2C_Open()
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/tirtos/2_20_00_06/exports/tirtos_full_2_20_00_06/products/tidrivers_full_2_20_00_08/docs/doxygen/html/struct_i2_c___params.html
[Originally Commented by @markhor ] I2C TivaC driver information is available at: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/tirtos/2_20_00_06/exports/tirtos_full_2_20_00_06/products/tidrivers_full_2_20_00_08/docs/doxygen/html/struct_i2_c_tiva___h_w_attrs.html#details
The header file: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/tirtos/2_20_00_06/exports/tirtos_full_2_20_00_06/products/tidrivers_full_2_20_00_08/docs/doxygen/html/_i2_c_tiva_8h_source.html
[Originally Commented by imgraham] While I agree that it would be good to have timeouts while using i2c to help guard against individual tasks getting halted, our system isn't susceptible to the system-wide halting linked above. The system halt bug is an issue with the MSP430 i2c driver implementation which could cause a stall within the HWI - the only way around this is to modify the driver. But like I said, this doesn't apply to us since Tiva uses a completely different implementation.
The good news is that the Tiva drivers seem to be more stable and properly handle devices not being present on the bus - I don't think we've ever seen this issue.
Unfortunately, if we wanted to still safeguard (which isn't a bad idea), the drivers bundled with TI-RTOS for Tiva don't provide the I2C_cancel function. So if we implemented timeouts, there isn't a proper way to stop a transfer in progress. Someone posted a workaround for the MSP430 (https://e2e.ti.com/support/embedded/tirtos/f/355/t/489991) but this requires messing with implementation internals and completely breaks portability. It might be safer to just rely on the watchdog for now if this ever happens.