Trouble with I2C devices on 2v25

[Nicktonious]

I had troubles with js modules for I2C devices since I switched to 2v25 on STM32F405-based board
First I noticed that my VL6180 no longer works correctly. I had failed to find the exact source of problems so I just re-written the module's logic. Maybe my module originally was inconsistent, but it definitly works on later versions.
What's more important, SHT31 module that has been tested for a long time doesn't work at all: it throws Timeout on I2C Write Transmit Mode 2
Noteworthy, both Vl6180 and SHT31 dont work on Hardware I2C an Software I2C setuped on hardware pins
What to you think about this bug? If you propose some tests, I'm ready to perform them and update my report

Thanks in advance!

[gfwilliams]

What's the clock speed on the F405 board? One thing that did change I recall is the I2C timeout got lowered - I forget exactly but from something like 0.5s to 0.1s - it feels like pretty much every I2C device should respond within under 1ms but maybe some don't?

[Nicktonious]

Clock speed is 168MHz
In a couple of days I'll be able to perform some complex tests on that board and another one. I'll share results ASAP

[gfwilliams]

Maybe try changing this line and rebuild and see if that fixes it? https://github.com/espruino/Espruino/blob/master/src/jshardware.h#L439

The boards we sell are 84Mhz, so 168 would halve the wait time. 2000000 at 168Mhz is probably only 50ms or so?

[ponyatov]

At low level and 100k low speed it works ok:

function test() {
  digitalWrite(A6,0); // trigger line
  I2C1.setup({
    scl:B8, sda:B9,
    bitrate: 100000
  });
  I2C1.writeTo(0x29, 0);
  var x = I2C1.readFrom(0x29, 6);
  digitalWrite(A6,1);
}
test();

[ponyatov]

At 400k I see the same working i/o.

So problem resides in incorrect I2C init or badly sensor high-level driver.

saleae Logic2 traces: i2c_2v25.zip

[gfwilliams]

I'm not sure I understand? So it works at 100k and 400k? When doesn't it work?

[ponyatov]

next test with LPS25HB pressure sensor:
firmware: Espruino 2v25.10
mcu: STM32F405

I see regular but not periodic faults every 2-30 seconds, with requests compressed after fault recovery.

In normal state sensor requests goes every 1 seconds.

Logic2 data: gap_2v25.sal.gz

[ponyatov]

2v25 with increased WAIT_UNTIL_N_CYCLES=5000000:

2v25_5000000.sal.gz

[ponyatov]

LPS25HB driver was omitted, and low-level code was done using sensor datasheet and this sample:
https://github.com/ControlEverythingCommunity/LPS25HB/blob/master/Arduino/LPS25HB.ino

Sensor works in continuous measurement mode (1 Hz) without any problems in a long time.

LPS25HB.js.gz
LPS25HB_raw.sal.gz

• WHO_AM_I
  

• setup
  

• measurement loop (pressure + temperature)
  

[Nicktonious]

I've tried to solve this problem on my own but that's something out of my capabilities. Some updates:

1. Lots of tests show that i2c exceptions are not actually periodical. Time between two errors varies from a couple of minutes to ~30mins
2. Increasing WAIT_UNTIL_N_CYCLES up to 5000000 actually leads to longer average period between errors on I2C but doesnt change the situation globally
3. I've successfully tested our 2v24 build - it works stable
4. While testing older builds I noticed that my drivers work just fine with bitrate 100kHz but if I set bitrate = 400kHz errors appear again
5. Then got back to 2v25 and found out that drivers work stable if I lower bitrate to 50kHz

So
2v25 i2c works stable only with bitrate lower than 100kHz
2v24 and older works stable with 100kHz

Is there any possibility that errors occur because espruino performs garbage collection and delays reading data?
Thanks in advance

[gfwilliams]

Is there any possibility that errors occur because espruino performs garbage collection and delays reading data?

No, I don't believe so. Espruino doesn't do I2C asynchronously (it blocks until all data is sent/received).

Is everything grounded correctly? It could be some kind of electrical interference, and maybe some change in Espruino causes more/less current draw immediately before the I2C comms which causes issues

If you can get the code so 2v24 works very repeatably and 2v25 always fails after a second or two, you could try git bisect which will allow you to try several different builds to basically binary search back through all the modifications in the code to find the one that broke it for you - that could be a good start?

[Nicktonious]

I'd like to add that actually decreasing frequency of i2c read/writings combined with keeping WAIT_UNTIL_N_CYCLES = 5000000 DEFIENETLY prevents errors spam. But that's still not a solution if we work with anything more complicated than a climate sensor.
My colleagues are not tend to believe that's a hardware problem, so we stay tuned and hope this problem might be solved in new versions of Espruino. Meanwhile, we’ll continue testing and will share any additional findings that may help.
We're working on the project involving Espruino in educational purposes and we can't just tell "students" not use hardware bus.
Thank you for your support