search

Telecominfraproject / OpenCellular

OpenCellular (OC) is open source access platform with main focus on rural connectivity. OC is an eco-system of open-source project(s) focusing on hardware, software, testing automation, manufacturing and building tools for ease of deployments and operations.
http://www.telecominfraproject.com/opencellular
Creative Commons Attribution 4.0 International
142 stars 38 forks source link

Bug: No timeout for I2C_MODE_BLOCKING #153

Open vthakur7f opened 6 years ago

vthakur7f commented 6 years ago

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

vthakur7f commented 6 years ago

[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

vthakur7f commented 6 years ago

[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

vthakur7f commented 6 years ago

[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.