Electronics > Microcontrollers

How many of you validate your I2C data in embedded systems?

<< < (4/5) > >>

globoy:
After some bone-headed mistakes, each wasting days, I finally captured a failure on the scope using another GPIO to trigger scope as wek suggested.  The scope trace below shows the failure.  It is the read data for a single-byte read.  You can see what appears to be the slave stretching the clock for about 27 uSec during the ACK phase.   The transaction appears to complete successfully after the clock stretching (the ESP32 issues a NACK indicating the end of the read).  The data (0x01) the slave delivers is correct data but the driver hands the code incorrect data (0xb4).  The driver does not indicate any I2C errors occurred.  So I am suspecting a rare issue in the ESP32 or its driver.  I have a work-around in the code that attempts to validate the data by looking for reserved bits being set or invalid combinations of bits.  But I guess I could try some additional back-burner experiments to try to further quantify the issue - more failure collection and see if I can come up with an experiment to see how often the slave clock stretches and if this correlates with the failure.

eutectique:

--- Quote from: globoy on June 11, 2023, 04:34:21 pm ---But I guess I could try some additional back-burner experiments to try to further quantify the issue - more failure collection and see if I can come up with an experiment to see how often the slave clock stretches and if this correlates with the failure.

--- End quote ---

I would use a spare dev board (or similar) to implement an I2C slave with controllable parameters. This way there would be no need to hunt for rare events that happen once in a blue moon.

cv007:

--- Quote ---The data (0x01) the slave delivers is correct data but the driver hands the code incorrect data (0xb4).
--- End quote ---
Not sure if that makes it easier or harder if the problem is only contained within the esp32 hardware/code, but it narrows the search. I think I would want to grab the i2c ram (and rx status) to see if the correct data is actually inside and the corruption is in the transfer of this i2c ram byte to somewhere else, or maybe the wrong byte is read from the i2c ram and the wrong value will be seen inside the i2c ram.

brumbarchris:
Nice catch! (on the scope)

I would second eutectique's suggestion above: just make another programmable i2c slave to send valid data, instead of your current slave. Do it by bit banging, so that you will have manual control to introduce any clock stretching as needed.

Cristian

hans:
Does my eye also spot that the data changes at seemingly random positions with respect to clock?

Sometimes it seems to be in the middle of clock transition, while other times it seems to occur at the falling edge.

Not sure when the I2C will read in the bit (hopefully the rising edge), but perhaps that could lead to some setup/hold time issues.

Otherwise this seems to be more of a RTL/software bug. Apart from the delay, which can be completely normal, the trace looks quite normal to me.

It is quite hard to explain how a byte 0x01 would change to 0xB4 unless some crazy stuff happens with the signal line (which doesn't appear to be, apart from the edges moving around), or some crazy stuff goes wrong with some buffer/statemachine. Maybe some interrupt is not serviced in time etc. If the target in question is ESP32, I would be quite cautious with that. I don't know if you use(d) ESP-IDF, but the bloat in that framework is IMO very substantial (although it does serve its purposes), and for issues like these I don't like random stuff thats in the background which, even worse, is not always clear whats happening.

Navigation

[0] Message Index

[#] Next page

[*] Previous page