Hi Support,
I am interfacing the DA14580 to a sensor using the i2c bus. Every now and then the sensor won't respond to a read request and my code gets hung up on WAIT_FOR_RECEIVED_BYTE(); . Since I am storing logged data in ram I don't want to use the watchdog timer to recover from this condition because a reset would clear all the logged data. Is there any way I can recover from this condition? Any suggestions would be greatly appreciated. Thanks.
Device:
Hi Dave,
You are right about that and there is an internal ticket to improve the i2c driver. An idea would be perhaps to implement a timeout handling with the hardware timers or even with a plain variable acting as a counter that would break the unconditional while loops if there is no activity from the slave side.
Thanks MT_dialog
Hi MT_dialog,
Is there any progress on this issue?
Hi yin,
We haven't updated our I2C drivers so far. Please have a look at this post, perhaps it will help you in order to implement a timeout when there is no response from the other side of the I2C connection.
https://support.dialog-semiconductor.com/i2c-communication-flow-protecti...
Thanks MT_dialog
Hi, Dialog,
Has this i2c driver issue fixed? Is there new driver release for this? I am facing this question as well.
Hi caiziee,
You can have a look at the latest 5.0.4 SDK for the i2c_eeprom example, the example has drivers that include a timeout scheme if there is no activity the device returns with an error code. But if there is no response from the sensor that you are using while reading data you will have to implement a custom scheme when its time to abord the interaction, a maximum time waiting for the received bytes or something similar.
Thanks MT_dialog
Hi, Dialog,
I am facing this question as well.According to the existing discussion, I did not find a feasible solution.Can you help me?
Hi DDDDragon
The reason why your code stacks in the WAIT_FOR_RECEIVED_BYTE, is why I2C_RXFLR_REG register has no data to receive from the I2C interface. So, you should check if the slave device responds. Also, you can probe the signals in order to check how frequently this happened, and if you prefer to not get stack in while(GetWord16(I2C_RXFLR_REG) == 0), you should do a similar implementation with ours but with timeout.
Thanks, PM_Dialog
Hi, PM_Dialog,
I have two from the device.According to my tests, there is no problem when you get data from the device, but once I read two data from the device at the same time, the program will stay WAIT_FOR_RECEIVED_BYTE for about an hour .I don't know much about timeouts. Can you give me an example?
Hi DDDDragon,
Could you please explain what do you mean with “two from the device” and read two data at the same time? Regarding the WAIT_FOR_RECEIVE_BYTE(), the macro checks the I2C_RXFLR_REG register that counts the received data, if you stay stuck in there it means that the other side hasn't send you anything yet. The device goes in wait state and waits for the other side to send the data that it should, so that the counter will increase and the 580 can go to the I2C FIFO and get the actual data. Did you try to use an analyzer in order to check if you receive data? If you receive data, the value of the I2C_RXFLR_REG should be non-zero. Could you please check that? A simple example of time-out is to have a for-loop instead of the while loop, so your code will continue after a certain amount of I2C_RXFLR_REG checks.
Thanks, PM_Dialog