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
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 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.
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.
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
