I2C Custom Logging Script Issue - I2C reads work at first, then randomly turns bad indefinitely

[pfprojects]

Hello!

I am trying to read registers from an I2C target with an Analog Discovery 2 in WaveForms>Protocol>I2C>Custom (Version 3.18.1), but I am encountering an issue with my script. Right now, I am reading several registers to log data over several hours. I start with a read of 0x1C with 4 bytes as the length, so I am essentially capturing 0x1C through 0x1F. Then, I do the same type of read with 18 bytes starting at 0x31, which means I am reading from 0x31 to 0x42. Each byte is stored in an array. Then, I perform some bit manipulation for the registers that are actually 16 bits in length. This method of reading the I2C data is then appended to a CSV and the loop will repeat itself at a rate of 1Hz for a couple hours. I've attached a snippet of the code, and I've also attached the full code in plain text to this post.

The problem is, after some random period of time in the CSV, the data ALL goes bad. ADC registers are hitting values that aren't possible or reasonable. Status registers look bad. Nothing looks real anymore in the data, and it stays that way until the whole several-hours-long I2C dump is finished. It never recovers from this bad state.

So my question is, is there a way to increase the robustness of the AD2 I2C controller? Is there something obvious I'm missing in my code? Am I messing something up with the buffer? I believe the data is becoming offset because of an erratic blip in either SDA or SCL, which might cause the Analog Discovery 2 to think it is data. It seems like the captured data gets shifted by a bit or two, then stays that way until another I2C error occurs and the bit offset changes once again. The problem is, this kind of blip only needs to happen once for the remainder of the log to come crashing down and become junk data. 

I know with past Arduino projects, if my serial buffer got really messed up, I could recover from that with a clever bit of code (see quote text block). Is there anything like this that I could perform with the AD2 to prevent the buffer from messing up the whole remainder of the data? I am using the AD2 in 100kHz mode with the FreqFilter on. With my current setup, I will admit it is entirely possible that I2C errors could occur; however, any errors captured should not be affecting my future measurements too. Obviously I can try to make the wire lengths better for signal integrity purposes, but I fear that this software error would persist with a lower chance of occurring. I can deal with random blips in the data, but right now I'm stuck with no usable data once the first error occurs.

Quote

// example of how to clear serial buffer in Arduino, to help convey what I'd like to maybe try
If(Serial.available() > 0)
{
    char t = Serial.read(); // clear the buffer into a temp char
}

I've attached the code I am using, which is stored in a plain text file (batscript.txt). Thank you all for your time.

-Pat

batscript.txt

Edited October 27, 2022 by pfprojects
Added SW version of WaveForms

[attila]

Hi @pfprojects

I've tried to reproduce the problem by disconnecting the wires while running. I got temporal bad data or "timeout error" if the I2C bus got stuck.
I suspect due to some ringing, crosstalk or external noise your I2C device receives a bad command and this causes protocol error or bad data reading.

Try using short wires, twisted with ground, stronger pull, series resistors... to reduce the chance of such glitches. Verify with Scope the signal quality.
I don't know which software version you are using but in newer the I2C states (for clock stretching) use internal DIO loopback to eliminate state crosstalk between long flying wires.
You are currently using the Sensor tab which uses hardware timer to repeat the loop. You could try using the Custom tab or Script tool with software loop to have more control and debug info, like if a Read call does not return the requested number of bytes back, or use Logic record to inspect the protocol and data.

 

Edited October 28, 2022 by attila