I2C bus timing error cause deadlock

⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.xmece.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
4 posts / 0 new
Last post
guxiang
Offline
Last seen:2 days 22 hours ago
加入:2017-05-12 04:18
I2C bus timing error cause deadlock

Hi, dialog
When we developed I2C device , we found there is a a low probability of bus timing error (as show in pdf file). At this point , if we used "ad_i2c_write" or "ad_i2c_read" to operate I2C bus , corresponding task would be suspend forever due to a code statement in "ad_i2c_write/read" function:
int ad_i2c_write(i2c_device dev, const uint8_t *wbuf, size_t wlen)
{
...
OS_EVENT_WAIT(dev_config->bus_data->event, OS_EVENT_FOREVER); //suspend forever
...
}

How to handle this error ? Can we set a specified waiting time in "OS_EVENT_WAIT(dev_config->bus_data->event, wait_time);" instead of waiting OS_EVENT_FOREVER?

Device:
MT_dialog
Offline
Last seen:4 months 2 weeks ago
Staff
加入:2015-06-08 11:34
Hi guixiang,

Hi guixiang,

I dont quite get what you mean an abnormal bus timing error and what exactly am i suppose to see on the .pdf that you have attached (apart from a failing i2c attempt). If the task is suspended and never resumed that means that the I2C transaction that you 've started apparently hasn't ended and the event that the task is waiting is never triggered (most probably because the slave device is streching the clock - keeps the clock line low). Bottom line, you could change the OS_EVENT_FOREVER and not wait for the event and set a specific wait time in ticks (which is not suggested), but you should verify what is the effect of this in your project, and also changing SDK files it is not recommended. What you should do is check why that happens, and the event never triggers, also please try to use the DMA in case that you dont use it, perhaps this will improve your setup.

Thanks MT_dialog

guxiang
Offline
Last seen:2 days 22 hours ago
加入:2017-05-12 04:18
Yes, according to the one

Yes, according to the one test device, when the task was suspended , the SDA line kept low , which is not the I2C bus idle state . We have about 50 devices , and 3 devices occured the similar situation in two month. Thus it 's very hard for us to capture the error and check why that happens due to the infrequence . And the DMA function is enabled

MT_dialog
Offline
Last seen:4 months 2 weeks ago
Staff
加入:2015-06-08 11:34
Hi guxiang,

Hi guxiang,

Apparently, this has to do with the sensor, and the sensor or memory that is connected on the 68x keeps the line low and therefore the the transfer is unable to complete (faulty connections, etc). You cannot just place a timeout instead of the OS_WAIT_FOREVER since you wont be aware the state of the I2C module or the state of the I2C adapter and thats why i am not in favor in replacing the OS_WAIT_FOREVER with waiting ticks, when messing with the adapter can cause serious issues. Regarding the time out on the i2c adapter, that feature isn't yet implemented on the SDK.

Thanks MT_dialog