Electronics > Microcontrollers
How many of you validate your I2C data in embedded systems?
wek:
Nice catch indeed!
How do you know it's the slave which stretches the clock?
(I use resistor divider to determine that using oscilloscope).
+1 to eutectique's suggestion.
JW
globoy:
--- Quote ---Does my eye also spot that the data changes at seemingly random positions with respect to clock?
--- End quote ---
I think this is the difference between the ESP32 driving the SDA line and the slave (a Silicon Labs EFM8SB micro) driving the SDA line. Earlier when debugging this design I did zoom in on I2C transactions involving different slaves and it does look like timing is being met.
In general millions and millions of transactions are executed successfully in periods stretching into multiple days. This problem only shows up rarely. Two of three slaves are accessed frequently (every 30 and every 100 mSec). The other slave is accessed very rarely.
--- Quote ---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.
--- End quote ---
It is strange and I agree, I wonder if some interrupt is missed or something. This is an IDF project and has has a handful of tasks running. Most of the time they should be pretty idle. Classic Bluetooth is also running and the device has been connected during my testing. I know BT runs at a high priority on the same CPU that is also doing I2C operations (I2C access is mutex protected for use with multiple tasks). My fear is that it's some more complicated set of conditions occurring that will be hard to reproduce in a dedicated setup.
I've done several products with the ESP32 and this is the first one where I've seen an issue with the I2C bus. A good thing is that I can probably dig into the driver and instrument it some (I've found I often have to look at the IDF source to figure something out).
--- Quote ---How do you know it's the slave which stretches the clock?
--- End quote ---
Actually, I don't. I made an assumption because I know the EFM8 can stretch the clock briefly for short periods. However you're right, it could be another chip and I've also done the trick of putting a resistor in series with SCL to find out who's pulling it low. It would be a pain to do that with this design (e.g. cutting traces, bodging in a resistor, etc) but probably could be done.
I have another capture running. When that one finishes I think I'm going to start another without Bluetooth connected to anything.
cv007:
--- Quote ---This problem only shows up rarely.
--- End quote ---
That you are aware of (?). Maybe there is more data corruption inside the esp32 i2c framework that goes unnoticed. If these are mostly single byte reads, it looks like the i2c peripheral will put the first read byte into the first i2c ram location so maybe you can compare all single byte read values with what is stored in the i2c ram which then requires just a single additional hardware read. If the values do not match, somewhere from hardware buffer to your result the value was corrupted. You would have to make sure the reading of the ic2 buffer takes place before another transaction is started. If there is more i2c data corruption than first thought, the simple verification could possibly speed up the 'catch' rate.
Navigation
[0] Message Index
[*] Previous page
Go to full version