I2C Timing off in 2.0.1 compared to 1.5.2. Debugging I2C

Firmware
#1

Hi,
We are trying our firmware on 2.0.1 from 1.5.2 on a boron and are having some issues reading data from our FRAM.
We are consistently seeing a “2: START bit generation timeout” when running the unmodified code on 2.0.1 where it works fine on 1.5.2.

Doing a Logic Analyse we can see that the i2c bus is somewhat slower in getting to start and stop bits on 2.0.1 vs 1.5.2
This is 1.5.2 where the start bit and stop bits are short 30uS as expected

image
image2256×520 22.7 KB

But on 2.0.1 these are nearly 3times slower
image
image2548×478 22.2 KB

What I’m confused about is how these timing could be so different between system firmware versions where the I2C should be Hardware powered. Unless I am mistaken and particle actually has a soft I2C Implementation?

I’m now a little stumped as to how to proceed to debugging and fixing this issue. Any sugguestions?

Thanks

2 Likes
#2

Hi @johnnyfp,

Thanks for reporting this. Could you please submit a support ticket and I’ll file it with the Device OS team. Ideally if you can share a minimal sketch demonstrating the bug that would be very helpful.

1 Like
#3

May have a similar issue. Is there a way to see what bugs have already been reported with 2.0.1?

#4

Please submit a ticket if you are seeing a specific issue. We have currently been unable to replicate the OPs bug and are working towards doing so.

Minimal changes were made to I2C when moving from 1.5.2 to 2.x.
Github provides some bug tracking, but we mainly deal with bugs internally. Please don’t rely on bugs submitted via Github. If you submit a ticket a support agent will drive it towards resolution.

#5

For me, It turned out to be a change in the way ATOMIC_BLOCKS work between the versions and how the I2C Sub process handles incoming reads in relations to interrupts.

Had to remove the call to I2C from the ATOMIC_BLOCKS for it to function again. However, the subtle timing difference observed between version still exist