i2c Write Issue

[PhilColbert]

Attaching a ms5611 ( GY86 ) to the esp32 on i2c - works perfectly for about 5-10 minutes - some strange values do come in however it seems to work pretty well.

Then loads of

[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 77

Board needs to be reset to start again

Any ideas?

Thanks

[stickbreaker]

@PhilColbert In Wire.cpp change TwoWire::reset() to this

void TwoWire::reset(void)
{
    i2cFreeQueue(i2c);
    i2cReleaseISR(i2c);
    i2cReset( i2c );
    i2c = NULL;
    begin( sda, scl );
}

and in your code where the Wire.endTransmission(true); is failing check for err=3

uint8_t err =Wire.endTransmission(true);
if(err==3){
  Wire.reset();
  } 

You'll have to change your code to retry that last operation.

Chuck.

[stickbreaker]

The only way I have been able to generate this condition is to ground SCL during a transmission.

Chuck.

[PhilColbert]

Well it should be possible to recreate but it does happen pretty randomly after a few minutes running - only had it twice in an hour recently but it does go again so if you would like to send me any code I can run and can debug this better ?

It ran perfectly until it starts erroring.

Hardware is

3.3v bus

connected to a GY86 board ( ms5611, MPU6050, MPU9250 )

Have other peripherals connected aswell ( gps and SPI lora board, running in a separate task ) - also out putting to a piezo on 2 channels.

Do you want to send any debug code so I can add or shall I just go ahead and add the reset code ?

Thanks for all the help - amazing work !

[PhilColbert]

2 hours up - still happy - looking good .... :)

[stickbreaker]

@PhilColbert I've been thinking, The bus busy error is a confusion issue. What I mean, is that the I2C bus is convinced that another master has started a transaction without completing it. The esp32 is "really" polite. It will never interrupt someone else's conversation. So it just sits there patiently waiting for it's turn. That never occurs. The Wire.reset() just starts over, clearing out this 'busy' state.

I am interested in why the SM think's another master is communicating. From your description you do not have any Other Masters on the I2C bus?

I was reading the MPU6050's data sheet, on page 34 of PS-MPU-6000A-00 REV 3.4 Release Date 08/19/2013, it says that it can stretch the SCL clock to pause the 'MASTER', Depending on how this is used, this could be the cause of the confusion. The DataSheet only has that one mention of the SCL clock stretching.

Chuck.

[stickbreaker]

@PhilColbert if you want to try a circuit change, put a signal diode, like a 1n914 inline on the SCL line between the ESP32 and the MPU6050. The cathode facing the ESP 32, also you will need pullup resistors on both sides. This diode would prohibit the MPU6050 from stretching SCL. The esp would never see the stretched pulse, so there might be some garbled communications. But the esp would not get into that 'confused' state. (if this clock stretching is the cause 🤒 )

Chuck.

[stickbreaker]

@PhilColbert next time you get an error, the First error is the most important. I've had more ideas (speculations) on what could be going wrong, but I need more data to crystallize my thinking. My latest musings are that the MPU6050 is creating a glitch on the SCL, or that the clock stretching is creating a timeout, or that the clock stretching is interfering with a STOP generation. Need more Info.

Chuck.

[PhilColbert]

Ok, will take the reset code out and log whats going on, do you want me to add anymore debugging lines or anything ?

This is the first error that comes out :-1:

[E][esp32-hal-i2c.c:1090] i2cProcQueue(): Gross Timeout Dead st=350502, ed=350552, =50, max=50 error=1 [E][esp32-hal-i2c.c:557] dumpI2c(): i2c=0x3ffc1df4 [E][esp32-hal-i2c.c:558] dumpI2c(): dev=0x60013000 [E][esp32-hal-i2c.c:559] dumpI2c(): lock=0x3fff64d4 [E][esp32-hal-i2c.c:560] dumpI2c(): num=0 [E][esp32-hal-i2c.c:561] dumpI2c(): mode=1 [E][esp32-hal-i2c.c:562] dumpI2c(): stage=3 [E][esp32-hal-i2c.c:563] dumpI2c(): error=1 [E][esp32-hal-i2c.c:564] dumpI2c(): event=0x3fff6568 bits=0 [E][esp32-hal-i2c.c:565] dumpI2c(): intr_handle=0x3fff4310 [E][esp32-hal-i2c.c:566] dumpI2c(): dq=0x3fff6cc0 [E][esp32-hal-i2c.c:567] dumpI2c(): queueCount=2 [E][esp32-hal-i2c.c:568] dumpI2c(): queuePos=1 [E][esp32-hal-i2c.c:569] dumpI2c(): byteCnt=1 [E][esp32-hal-i2c.c:574] dumpI2c(): [0] ee W buf@=0x3ffc9e5e, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:574] dumpI2c(): [1] ef R STOP buf@=0x3ffc9dd8, len=3, pos=0, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:902] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:905] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x00055926 [E][esp32-hal-i2c.c:905] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x00055926 [E][esp32-hal-i2c.c:905] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x00055926 [E][esp32-hal-i2c.c:905] i2cDumpInts(): [04] 0x0001 0x0002 0x0000 0x0000 0x00055926 [E][esp32-hal-i2c.c:1090] i2cProcQueue(): Gross Timeout Dead st=350659, ed=350709, =50, max=50 error=1 [E][esp32-hal-i2c.c:557] dumpI2c(): i2c=0x3ffc1df4 [E][esp32-hal-i2c.c:558] dumpI2c(): dev=0x60013000 [E][esp32-hal-i2c.c:559] dumpI2c(): lock=0x3fff64d4 [E][esp32-hal-i2c.c:560] dumpI2c(): num=0 [E][esp32-hal-i2c.c:561] dumpI2c(): mode=1 [E][esp32-hal-i2c.c:562] dumpI2c(): stage=3 [E][esp32-hal-i2c.c:563] dumpI2c(): error=1 [E][esp32-hal-i2c.c:564] dumpI2c(): event=0x3fff6568 bits=0 [E][esp32-hal-i2c.c:565] dumpI2c(): intr_handle=0x3fff4310 [E][esp32-hal-i2c.c:566] dumpI2c(): dq=0x3fff7748 [E][esp32-hal-i2c.c:567] dumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:568] dumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:569] dumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:574] dumpI2c(): [0] ee W STOP buf@=0x3ffc9e5e, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:902] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:905] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x000559c3 Elapsed 866120us bAlt = 1009345 kfAlt = 19965 kfVario = 13 [E][esp32-hal-i2c.c:1090] i2cProcQueue(): Gross Timeout Dead st=350791, ed=350841, =50, max=50 error=1 [E][esp32-hal-i2c.c:557] dumpI2c(): i2c=0x3ffc1df4 [E][esp32-hal-i2c.c:558] dumpI2c(): dev=0x60013000 [E][esp32-hal-i2c.c:559] dumpI2c(): lock=0x3fff64d4 [E][esp32-hal-i2c.c:560] dumpI2c(): num=0 [E][esp32-hal-i2c.c:561] dumpI2c(): mode=1 [E][esp32-hal-i2c.c:562] dumpI2c(): stage=3 [E][esp32-hal-i2c.c:563] dumpI2c(): error=1 [E][esp32-hal-i2c.c:564] dumpI2c(): event=0x3fff6568 bits=0 [E][esp32-hal-i2c.c:565] dumpI2c(): intr_handle=0x3fff4310 [E][esp32-hal-i2c.c:566] dumpI2c(): dq=0x3fff7748 [E][esp32-hal-i2c.c:567] dumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:568] dumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:569] dumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:574] dumpI2c(): [0] ee W STOP buf@=0x3ffc9e5e, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:902] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:905] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x00055a47 [E][esp32-hal-i2c.c:1090] i2cProcQueue(): Gross Timeout Dead st=350918, ed=350968, =50, max=50 error=1 [E][esp32-hal-i2c.c:557] dumpI2c(): i2c=0x3ffc1df4 [E][esp32-hal-i2c.c:558] dumpI2c(): dev=0x60013000 [E][esp32-hal-i2c.c:559] dumpI2c(): lock=0x3fff64d4 [E][esp32-hal-i2c.c:560] dumpI2c(): num=0 [E][esp32-hal-i2c.c:561] dumpI2c(): mode=1 [E][esp32-hal-i2c.c:562] dumpI2c(): stage=3 [E][esp32-hal-i2c.c:563] dumpI2c(): error=1 [E][esp32-hal-i2c.c:564] dumpI2c(): event=0x3fff6568 bits=0 [E][esp32-hal-i2c.c:565] dumpI2c(): intr_handle=0x3fff4310 [E][esp32-hal-i2c.c:566] dumpI2c(): dq=0x3fff7748 [E][esp32-hal-i2c.c:567] dumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:568] dumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:569] dumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:574] dumpI2c(): [0] ee W STOP buf@=0x3ffc9e5e, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:902] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:905] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x00055ac6 [E][esp32-hal-i2c.c:1090] i2cProcQueue(): Gross Timeout Dead st=351045, ed=351095, =50, max=50 error=1 [E][esp32-hal-i2c.c:557] dumpI2c(): i2c=0x3ffc1df4 [E][esp32-hal-i2c.c:558] dumpI2c(): dev=0x60013000 [E][esp32-hal-i2c.c:559] dumpI2c(): lock=0x3fff64d4 [E][esp32-hal-i2c.c:560] dumpI2c(): num=0 [E][esp32-hal-i2c.c:561] dumpI2c(): mode=1 [E][esp32-hal-i2c.c:562] dumpI2c(): stage=3 [E][esp32-hal-i2c.c:563] dumpI2c(): error=1 [E][esp32-hal-i2c.c:564] dumpI2c(): event=0x3fff6568 bits=0 [E][esp32-hal-i2c.c:565] dumpI2c(): intr_handle=0x3fff4310 [E][esp32-hal-i2c.c:566] dumpI2c(): dq=0x3fff7748 [E][esp32-hal-i2c.c:567] dumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:568] dumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:569] dumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:574] dumpI2c(): [0] ee W STOP buf@=0x3ffc9e5e, len=1, pos=1, eventH=0x0 bits=0

[stickbreaker]

@PhilColbert That first error shows clock stretching.

[E][esp32-hal-i2c.c:567] dumpI2c(): queueCount=2
[E][esp32-hal-i2c.c:568] dumpI2c(): queuePos=1
[E][esp32-hal-i2c.c:569] dumpI2c(): byteCnt=1
[E][esp32-hal-i2c.c:574] dumpI2c(): [0] ee W buf@=0x3ffc9e5e, len=1, pos=1, eventH=0x0 bits=0
[E][esp32-hal-i2c.c:574] dumpI2c(): [1] ef R STOP buf@=0x3ffc9dd8, len=3, pos=0, eventH=0x0 bits=0
[E][esp32-hal-i2c.c:902] i2cDumpInts(): row count INTR TX RX
[E][esp32-hal-i2c.c:905] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x00055926
[E][esp32-hal-i2c.c:905] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x00055926
[E][esp32-hal-i2c.c:905] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x00055926
[E][esp32-hal-i2c.c:905] i2cDumpInts(): [04] 0x0001 0x0002 0x0000 0x0000 0x00055926

These are the interesting lines, The DumpInts[] show that the first command when through the hardware. [01] the txFifo was loaded with 3 bytes, the: beginTransmission(0x77), Write(byte), and then requestFrom(0x77) address. [02] says the SM started processing the command queue [03] says 3 bytes were moved, the beginTransmission(0x77), the Data Byte write, then the ReSTART with the requestFrom(0x77). [04] is just the txEmpty request, The SM wants the txFifo to have at least 4 bytes, but, alas, you didn't want to send that many.

No more interrupts were generated, thefore the bus was busy, probably SCL was being stretched.

I hard coded a 50ms timeout in i2cProcQueue(), it looks like this device can exceed this timeout. Do you have any idea on the maximum timeout this device can generate?

I don't see any failure, just the 0x77 device hanging. What was the command you sent? What did it ask from the device?

Try increasing the 50ms timeout in esp32-hal-i2c.c:1033

//hang until it completes.

// how many ticks should it take to transfer totalBytes thru the I2C hardware,
// add 50ms just for kicks

portTickType ticksTimeOut = ((totalBytes /(i2cGetFrequency(i2c)/(10*1000)))+50)/portTICK_PERIOD_MS;
portTickType tBefore=xTaskGetTickCount();  

change that +50 to maybe +500 (from 1/20 sec to 1/2 sec)

Chuck.

[stickbreaker]

@PhilColbert just committed with a new Wire.h function Wire.setTimeOut(millis); It defaults to 50ms but you can set it where ever you want. You can change it for different devices.

Chuck.

[PhilColbert]

Thanks - just off out for a day or so - will check when I return- good idea about different devices !

[stickbreaker]

@PhilColbert I updated my repo. Have you had any success?

Chuck.

[me-no-dev]

@stickbreaker I am diving in your I2C code today ;) What is the best way to keep in touch?

[stickbreaker]

@me-no-dev Probably email ctodd at cableone dot net GMT-6 7am:9pm

Chuck.

[PhilColbert]

All seems good here now :) thanks !

[stickbreaker]

@PhilColbert Since you are satisfied, close the issue.

[rlerdorf]

Stumbled on this and since switching to your fork my i2c bus, which used to lock up after 6-7 hours, has now survived for 2 days. (Wroom-32 with just a BME280 on i2c) Thanks

[stickbreaker]

@rlerdorf That's what I like hearing. @me-no-dev is reviewing the code for inclusion into the main branch. Hopefully in the near future, I2C will be a non issue.

Chuck.

[ifrew]

Hi Chuck,

I'm working with Phil Colbert on same project. I took your latest wire.cpp and .h, and esp32_hal_i2c.c and .h today and put them in my project as I was getting the same gross timeout errors. Reading through this thread and talking to Phil I see that you had suggested using a reset if endtransmission returned err-==3

uint8_t err =Wire.endTransmission(true); if(err==3){ Wire.reset(); }

But later you suggest changing the timeout to be greater than 50ms. I have set that to 500ms now and my code is running with no reset in my code. But I am seeing these debug statements regarding timing recovery. Do I still need to do a reset if err ==3?

[E][esp32-hal-i2c.c:1113] i2cProcQueue(): TimeoutRecovery: expected=0ms, actual=2ms [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc12bc [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff4a80 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff4b18 bits=10 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff4b48 [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffd8b6c [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=2 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] d0 W STOP buf@=0x3ffc6f76, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: ; 3b [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x00045c54 [E][esp32-hal-i2c.c:945] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x00045c54 [E][esp32-hal-i2c.c:945] i2cDumpInts(): [03] 0x0002 0x0040 0x0000 0x0000 0x00045c54 [E][esp32-hal-i2c.c:945] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x00045c54

[stickbreaker]

@ifrew This debug message can be commented out, It is something to see if the StateMachine could recover from a INTR 0x100 timeout. the dump you posted is kind of confusing. I says 'TimeoutRecovery' but there was NO timeout? The expected=0ms, actual=2ms is just showing that between the time that procQueue() marked it's start and when the ISR returned took longer than calculated. I would have you place a block comment around that warning;

Starting at line 1109 thru 1118 of esp32-hal-i2c.c:

if(eBits&EVENT_DONE){ // no gross timeout
/* add this block comment @ifrew
#if ARDUHAL_LOG_LEVEL >= ARDUHAL_LOG_LEVEL_ERROR
  uint32_t expected =(totalBytes*10*1000)/i2cGetFrequency(i2c);
  if((tAfter-tBefore)>(expected+1)) { //used some of the timeout Period
    // expected can be zero due to small packets
    log_e("TimeoutRecovery: expected=%ums, actual=%ums",expected,(tAfter-tBefore));
    i2cDumpI2c(i2c);
    i2cDumpInts();
    }
#endif
Clear to there @ifrew */ 
  switch(i2c->error){
    case I2C_OK :
      reason = I2C_ERROR_OK;
      break;
    case I2C_ERROR :
      reason = I2C_ERROR_DEV;
      break;
    case I2C_ADDR_NAK:
      reason = I2C_ERROR_ACK;

It looks like you have higher priority processes that are delaying procQueue(). This delay is not a problem. So, the error message is just a distraction.

On the I2C_ERROR_TIMEOUT (3), a valid TimeOut should only exist if:

• Your I2C bus has multiple masters
• One of your I2C Devices does SCL stretching (clock Stretching) for delay or sync purposes

If neither of these are true, then a TimeOut is indicative of a bus problem, and the Wire.Reset() is the only solution. @lonerzzz has a device that does clock stretching. When he initiates a READ Wire.requestFrom() it can hang the bus for up to 2 seconds. The problem is that the ESP32 does not recover correctly. The TimeOut aborts the current transaction. Instead of just delaying it. So, he has to reissue the READ command to acquire the data. With his device, Wire.reset(); does not recover the bus because the SLAVE is still holding SCL. So, He just re-issues the READ with a long timeout until it is successful. Once the SLAVE release SCL the StateMachine can accept new transactions without a Wire.reset().

Chuck.

[ifrew]

Awesome info! many thanks. I have read about clock issues and the i2c bus on this device we are using not fully adhering to the i2c spec so appreciate all the work you guys are doing.

[ifrew]

Well Chuck after putting in the reset and increasing the timeout it runs for a while and I was really happy but after about 15-20 min it starts doing this repeatedly [E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd2f5b, end=0xd2f8d, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5194 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff522c bits=0 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff525c [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffd8a98 [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W STOP buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: X 58 [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x000d2f5b [E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd2fe7, end=0xd3019, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5194 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff522c bits=0 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff525c [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffd8a98 [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W STOP buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: X 58 [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x000d2fe7 [E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd3073, end=0xd30a5, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5194 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff522c bits=0 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff525c [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffd8a98 [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W STOP buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: X 58 [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x000d3073 $LK8EX1,101596,-22,-8,25,03A $LK8EX1,101596,-22,-8,25,03A $LK8EX1,101596,-22,-8,25,03A $LK8EX1,101596,-22,-8,25,03A $LK8EX1,101596,-22,-8,25,03A $LK8EX1,101596,-22,-8,25,03A $LK8EX1,101596,-22,-8,25,03A $LK8EX1,101596,-22,-8,25,03A $LK8EX1,101596,-22,-8,25,03A $LK8EX1,101596,-22,-8,25,03A $GPRMC,,V,,,,,,,,,,N53 $GPVTG,,,,,,,,,N30 $GPGGA,,,,,,0,00,99.99,,,,,,48 $GPGSA,A,1,,,,,,,,,,,,,99.99,99.9[E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd30fe, end=0xd3130, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5194 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 9,99.9930 $GPGSV,1,1,0079 $GPGLL,,,,,,V,N64 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff522c bits=0 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff525c [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffd8a98 [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W STOP buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: X 58 [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x000d30fe Elapsed 480384us bAlt = 584820 kfAlt = -2261 kfVario = -8 [E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd31a4, end=0xd31d6, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5194 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff522c bits=0 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff525c [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffd8a98 [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W STOP buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: X 58 [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x000d31a4 [E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd3230, end=0xd3262, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5194 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff522c bits=0 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff525c [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffd8a98 [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W STOP buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: X 58 [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x000d3230 [E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd32bc, end=0xd32ee, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5194 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff522c bits=0 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff525c [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffd8a98 [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W STOP buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: X 58 [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x000d32bc [E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd3348, end=0xd337a, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5194 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff522c bits=0 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff525c [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffd8a98 [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W STOP buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: X 58 [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x000d3348 [E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd33d4, end=0xd3406, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5194 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff522c bits=0 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff525c [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffd8a98 [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W STOP buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: X 58 [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x000d33d4 [E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd345f, end=0xd3491, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5194 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff522c bits=0 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff525c [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffd8a98 [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W STOP buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: X 58 [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x000d345f $LK8EX1,101596,-22,-8,25,03A $LK8EX1,101596,-22,-8,25,03A $LK8EX1,101596,-22,-8,25,03A $LK8EX1,101596,-22,-8,25,03A $LK8EX1,101596,-22,-8,25,03A $LK8EX1,101596,-22,-8,25,03A $LK8EX1,101596,-22,-8,25,03A $LK8EX1,101596,-22,-8,25,03A $LK8EX1,101596,-22,-8,25,03A $GPRMC,,V,,,,,,,,,,N53 $GPVTG,,,,,,,,,N30 $GPGGA,,,,,,0,00,99.99,,,,,,48 $GPGSA,A,1,,,,,,,,,,,,,99.99,99.9[E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd34ea, end=0xd351c, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5194 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff522c bits=0 9,99.9930 $PFLAU,6,1,2,1,0,144,0,235,44655 $LK8EX1,101596,-22,-8,25,03A $GPGSV,1,1,0079 $GPGLL,,,,,,V,N*64 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff525c [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffd8a98 [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W STOP buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: X 58 [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x000d34ea Elapsed 476283us bAlt = 584820 kfAlt = -2261 kfVario = -8 [E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd358e, end=0xd35c0, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5194 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff522c bits=0 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff525c [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffd8a98 [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W STOP buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: X 58 [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x000d358e [E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd361a, end=0xd364c, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5194 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff522c bits=0 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff525c [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffd8a98 [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W STOP buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: X 58 [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x000d361a [E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd36a5, end=0xd36d7, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5194 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff522c bits=0 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff525c [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffd8a98 [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W STOP buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: X 58 [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x000d36a5 [E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd3730, end=0xd3762, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5194 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff522c bits=0 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff525c [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffd8a98 [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W STOP buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: X 58 [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x000d3730 [E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd37bc, end=0xd37ee, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5194 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff522c bits=0 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff525c [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffd8a98 [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W STOP buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: X 58 [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x000d37bc [E][esp32-hal-i2c.c:1

[lonerzzz]

@ifrew Can you state what the SDA and SCL lines are doing when the failure happens? The Wire.reset() call just resets the state machine on ESP32 but how you are able to proceed depends on the state of peripheral as well. @stickbreaker and I have been throwing around ideas on how to handle. Currently, I have the ability to toggle the enable pin on my I2C slaves and have been using that. You could also toggle power. The other option is trying to toggle the SCL line manually to get the slave out of the funny state if it is in one.

[ifrew]

Hi @lonerzzz,

Its early morning here. Unfortunately I don't have any scopes to check out the lines. However, after reading Chucks excellent doc https://github.com/stickbreaker/arduino-esp32/blob/master/libraries/Wire/docs/README.md just now I don't think I'm reading the i2c bus correctly to take advantage of his queuing. I'm using the Jeff Rowen I2Cdevlib library. When I get up I will modify that code to read the bus as per the new method recommended by Chuck and see what happens. I hadn't fully understood that there were some modifications to make as to how the bus should be read to avoid the timeouts. Sometimes it runs for a while other times it doesn't so looks like I have been lucky as to when the FreeRTOS scheduler switches tasks when I am reading the bus. With my sensor I'm reading the bus every 10ms via interrupts.

[stickbreaker]

@ifrew

With my sensor I'm reading the bus every 10ms via interrupts.

Are you doing a Wire() call from an interrupt? This library (Wire()) is not re-entrant. It assumes only one thread is accessing it. It does not serialize access.

Chuck.

[stickbreaker]

@ifrew This debug dump show the I2C bus is HUNG. Some type of reset is necessary, The Wire.reset() will clear the I2C hardware of the ESP32, but it may not reset any slave Devices. @lonerzzz comment enable/reset/power on will be required. If the bus is hung because SDA is low, I have also used another pin to stimulate SCL. Connect a signal diode (1n914,1n4148) from another digital pin to SCL. Cathode on SCL. Do a sequence of 9 digitalWrite(pin,LOW); digitalWrite(pin,HIGH); this should cause any slave to release SDA. If SCL is LOW(problem) some type of hardware reset is required. The ESP32 can only release it's drive of the the Bus, it cannot force another Device to release it.

Chuck.

[ifrew]

Great info Chuck. In my ISR I only set a Boolean to signify data can then be read and return. Main loop checks the Boolean. Should be good there. I have a different mpu/ms5611 board I can try but I think that the underlying problem lies with the mpu6050 not adhering to the I2C protocol. The other mpu board I have with ms5611 on board is a 9250. This may be a better board to use but its just a 6050 with a magnetometer. For reference, this discussion seems to match what you found here. Looks like SDA is latched low and only a reset like you discussed is a fix. https://github.com/jrowberg/i2cdevlib/issues/252

[ifrew]

An update for you guys. before I changed any code, I swapped out the mpu6050/ms5611 board for a mpu9250/ms5611 board and got same issues as above. So that at least was good to know. Swapped back to the mpu6050/ms5611 board and verified that I still got same errors.

I then noticed from Chuck's analysis that the address of the device was 0x77 that was get the bus busy errors. That is the MS5611 pressure sensor. So I thought I would at least clean up the code that was reading the sample to be in accordance with how Chucks said it should be read.. Before it was the traditional method. So now it is as follows

uint32_t MS5611::ReadSample(void) { //Serial.println("RS"); Wire.beginTransmission(MS5611_I2C_ADDRESS); // Initialize the Tx buffer Wire.write(0x00); // Put ADC read command in Tx buffer uint8_t err = Wire.endTransmission(false); // keep connection alive if (err == 7) { uint8_t count = Wire.requestFrom(MS5611_I2C_ADDRESS, 3); if (Wire.lastError() != 0) { Serial.printf("Bad Stuff!!\nRead of (%d) bytes read %d bytes\nFailed" " lastError=%d, text=%s\n", 3, count, Wire.lastError(), Wire.getErrorText(Wire.lastError())); } int inx = 0; uint8_t buf[3]; while (Wire.available()) { buf[inx++] = Wire.read(); } uint32_t w = (((uint32_t)buf[0]) << 16) | (((uint32_t)buf[1]) << 8) | (uint32_t)buf[2]; return w;

}
else return 0;

}

Compiled and its now running with no errors yet as opposed to the errors I got last time. Not getting any 0 values returned yet either. I am expecting that since I am now waiting for the queued read to be available,, timing wise, the bus becomes free at some point and all is working. Will go out for lunch and drive around with my device running for a while and see what I get. will report back later

[ifrew]

Ok.. spoke too soon! Bus hang again. Ok.. So now confirmed that the mpu6050 is keeping the bus busy. Will need to do the hardware reset trick you had thought of above.

[stickbreaker]

@ifrew Sounds like you have identified the problem. Now to construct a reliable recovery method. Good Luck.

Chuck.

[ifrew]

@stickbreaker I had a thought over the last day as to why Phil's code is running fine and I was getting errors so I got him to send me his 4 files from your forked build ie the wire and esp32-hal-i2c files. I put them in and voila mine is working fine now. I did a comparison and I can see quite a few changes. The wire.cpp file seems overall to be the same with the exception of some field size changes. However there are quite a few changes in the ep32-hal-i2c file that I think are causing issues, ie a regression from what phil and I have working now. Looking though your code, and I am not an expert by no means in what you have written, I see that the gross timeout is handled differently. In your latest code I am getting those then busy timeouts then bus hangs. In the older code it works fine. I am attaching the four files so you can compare and see if you can think why the earlier version works fine and the latest doesn't . Many thanks for all of this BTW. Phil and I would be stuck otherwise.

esp32-hal-i2c.c.zip

[stickbreaker]

@ifrew I'll study the differences, Can you explain the differences between what you are seeing as compared to Phil?

Chuck.

[ifrew]

With the code from your earlier fork, it is running fine now for both Phil and I. Phil hasn't tried the latest fork from you so isn't seeing any errors now. Both of us are using the exact same hardware and configuration. I would expect if Phil used the latest 4 files he would get same issue. From the last dump I sent above that you said was a bus hang, the only part of the trace missing I noticed now was the initial gross timeout error before all the busy timeouts occurred. I can repo and send you the initial gross timeout message if would help you?

[stickbreaker]

@ifrew yea, send me the complete debug output. here or in my mail box ctodd at cableone dot net.

chuck.

[ifrew]

Dang.. I think I may have found the issue! I left the code that was working yesterday running overnight and it was still running this morning after 18hours. I then ran your code that I said failed and it was still running after 40minutes, longer than it had been. Strange I thought, so I picked up my device which is on a breadboard and for some reason I decided to check the wires..bang..the error occurred as attached in the debug output. So I thought that my SDA or SCl line may have not had a goof connection. So I reset them and its running now. I then pulled out the SCL line and all ran, albeit with incorrect resuls for my app, but then put it back and it started working again. I then pulled off the SDA line and bang..the timeout errors appeared.

So it looks like I may have had a flaky SDA connection. When I look at the code difference from your latest versus what you had before, I see that you now let through the gross timeout errors whereas before you didn't.

So now I am going to leave your latest code running and see what happens! How frustrating and bad of me to waste your time if this is the issue. Dang it!

I will post an update later if all is still running.

putty.txt

[ifrew]

Still running after 2:45 now...I think that was the issue. Sorry guys.

[stickbreaker]

@ifrew Well, keep testing it. I do need to clean out some of the debug code anyway. I tend to contemplate a problem before I start chasing it, so I had not written any new code yet. I'll look through your debug capture and think about how to use the events to detect/report SDA issues more succinctly. Right now no one trusts the I2C bus so they don't trust the Error messages to be accurate. I am hoping this revision will gain the trust back.

Chuck.

[ifrew]

Well @stickbreaker it bombed out again . I don't know how long it had been running but less than 12 hours with your latest code. So the old code seems to work better. I looked at it thoroughly today and there are really little changes I could see but there are a couple of places in the hal code that may make a difference. I hadn't touched my setup at all after I made sure the connections were right but another gross timeout occurred. I should state i'm using your default of 50ms. However since Phil and I had it running longer with your old version than the latest version there is something in there that seems strange.. I have a 201MB log file output but still the same gross timeout that occurred first..

[E][esp32-hal-i2c.c:1159] i2cProcQueue(): Gross Timeout Dead start=0xd67ece, end=0xd67f00, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5180 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff5218 bits=0 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff5248 [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3fff57e8 [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=2 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=1 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=1 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: . 00 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [1] ef R STOP buf@=0x3ffc6e90, len=3, pos=0, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: ... 01 18 ff [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x00d67ece [E][esp32-hal-i2c.c:945] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x00d67ece [E][esp32-hal-i2c.c:945] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x00d67ece [E][esp32-hal-i2c.c:945] i2cDumpInts(): [04] 0x0001 0x0002 0x0000 0x0000 0x00d67ece [E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd67f81, end=0xd67fb3, =50, max=50 error=1 [E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc125c [E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000 [E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3fff5180 [E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0 [E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1 [E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3 [E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1 [E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3fff5218 bits=0 [E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3fff5248 [E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3fff5a4c [E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1 [E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0 [E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=0 [E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W STOP buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0 [E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: X 58 [E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX [E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0002 0x0000 0x00d67f81 [E][esp32-hal-i2c.c:1149] i2cProcQueue(): Busy Timeout start=0xd6800d, end=0xd6803f, =50, max=50 error=1

[stickbreaker]

@ifrew

[E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=2
[E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=1
[E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=1
[E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] ee W buf@=0x3ffc6f16, len=1, pos=1, eventH=0x0 bits=0
[E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: . 00
[E][esp32-hal-i2c.c:582] i2cDumpDqData(): [1] ef R STOP buf@=0x3ffc6e90, len=3, pos=0, eventH=0x0 bits=0
[E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: ... 01 18 ff
[E][esp32-hal-i2c.c:942] i2cDumpInts(): row count INTR TX RX
[E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x00d67ece
[E][esp32-hal-i2c.c:945] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x00d67ece
[E][esp32-hal-i2c.c:945] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x00d67ece
[E][esp32-hal-i2c.c:945] i2cDumpInts(): [04] 0x0001 0x0002 0x0000 0x0000 0x00d67ece

base on this debug, the Wire.requestFrom(0x77,3) is where the problem happened. The StateMachine(SM) sent out the

Wire.beginTransmission(0x77);
Wire.write(0);
Wire.endTransmission(false);

When it started the requestFrom() the slave acknowledged the read command, then started stretching SCL. My library worked correctly. The slave device / I2C bus is causing the problem. There is nothing I can do from software to make a slave release the SCL signal.

Other people have had I2C issues that have been resolved by having the correct pullup resistance. One person when from 10k pullups to 2.4k and their problems disappeared. If you are using 3.3V I2C the pullups should be between 1k and 3.3k, for 5V 1.8k to 4.7k. If you have the bus speed at 100kzHz the higher values. As the bus speed increases more power is needed, so the pullup resistor values need to be reduced.

The default timeout for the library is 50ms you can increase it with Wire.setTimeout(uint16_t millisec); The library can handle this SCL stretching, but the Timeout Value needs to be longer than the SCL stretching period. @lonerzzz has to use a 2000ms timeout because one of his devices can stretch SCL that long. If my library issues a I2C_ERROR_TIMEOUT your application will have to do some error recovery. My library will just shutdown the I2C hardware and return.

The SM may not handle the timeout caused by a SCL stretching event correctly, (I haven't been able to test it). @lonerzzz has a device that does this SCL stretching. after a SCL stretching event, his requestFrom() fails to transfer the data, but the SM closes the transaction correctly with a STOP. So his next call succeeds. The library returns I2C_ERROR_TIMEOUT, he uses this value to re-issue the requestFrom(). If he receives I2C_ERROR_BUSY he issues Wire.reset(); to recover the bus.

If the specified timeout expires, The bus will be left in a ERROR state. This shutdown may be the error cascade start point. Since the SM is the 'current' master, and it is in a transaction (START has be issued), but the specified timeout (50ms) has expired. This expired timeout causes the abort. (shutting down the SM). Since the bus is currently busy(SCL held low), the SM cannot close the transaction with a STOP(SDA going high while SCL is HIGH). The SM knows the 'current' bus state is busy, because it saw a START (the one it send out) but has not seen a STOP(abort canceled the transaction so it will NEVER SEND a STOP). From this point forward the SM will be hung waiting for someone to issue a STOP. It will wait forever.

This busy condition will inhibit the SM from using the I2C bus. Until it sees the bus clear (STOP detected, SCL HIGH, SDA HIGH).

The application needs to issue a Wire.reset() if warranted.

Bus Busy is a valid condition in a multimaster environment. If another master is using the bus the ST will wait up to the timeoutPeriod to execute it's commands. In your case, is sounds like the bus is hung by something else, either a Slave device stretching SCL, or a noise spike on SDA that is interpreted as a START. If the SDA line goes low while SCL is high, the SM will interpret that event as a START by another master. It will listen on the bus for a STOP, (SDA going HIGH while SCL is already HIGH). until this STOP is heard the SM will not attempt to use the bus.

What is the device at 0x77 I would like to read it's datasheet to try to understand what it is doing.

Chuck.

[ifrew]

Always great to read your detailed responses as I learn something new all the time. ! Many thanks. Currently i do not have pullups on the sda/scl lines. I haven't checked but i am assuming the wire library implementation enables the internal pull ups using the i2c hal code? I was going to check that today and add external pull-ups so your response comes at the right time. The device we are using is a gy-86 breakout board. This contains a ms5611 pressure sensor at 0x77 and a mpu6050 0x68 on the same bus. Based on the info you gave and other threads i have read the mpu6050 seems not to strictly adhere to i2c protocol implementation and can latch the sda low. I expect this is what is happening and when i then try and access the ms5611 i get the bus busy errors.

So sounds like the earlier code with it running for 18hrs once may be just a fluke and at some point it may fail?

[stickbreaker]

@ifrew The internal pullups are in the range of 30k to 50k. Not enough.

The newer code implements bus busy return codes. Older code had a longer configured timeout.

Chuck.

[stickbreaker]

@ifrew Reading through the MS5611 spec sheet it does NOT say to use a ReSTART when you select the register for read

Wire.beginTransmission(0x77);
Wire.write(0x48); // initial pressure conversion 
Wire.endTransmission();
// conversion can take up to 9ms
uint32_t timeout=millis();
bool ready=false;
uin32_t reading=0;
while(!ready && (millis()-timeout<10ms)){
  Wire.beginTransmission(0x77);
  Wire.write(0);
  ready = (Wire.endTransmission()==0);
  }
If(ready){
  Wire.requestFrom(0x77,3);
  if(Wire.lastError==0){
    while(Wire.available){
      reading = reading << 8;
      reading = reading + Wire.read();
      }
    }
  else {
    Serial.printf("Read of pressure sensor failed (%u)=%s\n",Wire.lastError(),Wire.getErrorText(Wire.lastError())));
    }
  }
else {
  Serial.printf("Sensor did not finish conversion within 10ms");
}

Chuck.

[stickbreaker]

@ifrew Are you actually using a gy-86? all of the schematics I can find show a module designed to interface to a 5v CPU.

They have level shifters and a 3.3v regulator onboard? 4.7k pullup to 5v and 4.7 pullup to 3.3v equiv of 2.8k to 5v?

Chuck.

[ifrew]

Yes using the gy-86. Voltage input can be from 3.3v to 5v. It has an onboard regulator and pull up resistors seemingly but i don't know the values of those. I can't find schematics either. Do i need to disable internal pullups before adding externals in range 1k to 3.3k? I have been using this board with the same drivers running on esp8266 and no pullups without issues for many months. On the esp32, due to multiple cores and task switching as you pointed out we can get timeouts.

The code I am using to read the sensor is

uint32_t MS5611::ReadSample(void) {

Wire.beginTransmission(MS5611_I2C_ADDRESS);  // Initialize the Tx buffer

Wire.write(0x00);                        // Put ADC read command in Tx buffer

Wire.endTransmission(false);        // Send the Tx buffer, but send a restart to keep connection alive

Wire.requestFrom(MS5611_I2C_ADDRESS, 3);     // Read three bytes from slave PROM address 

int inx = 0;

uint8_t buf[3];

while (Wire.available()) {

    buf[inx++] = Wire.read(); 

    }          

uint32_t w = (((uint32_t)buf[0])<<16) | (((uint32_t)buf[1])<<8) | (uint32_t)buf[2];

return w;

}

I got this from another project on GitHub.

[stickbreaker]

@ifrew If it is similar to the schematic I found, it already has a low enough resistance, don't add more. The built in pullups are inconsequential.

That code I posted was base on my reading of the datasheet. in the SPI section is show a 8.02ms delay while the conversion is in progress, the sdo line is used as a 'READY' signal. on Page 3 is a table of conversion time. Different resolutions have different times.

The code you just posted is only reading the last conversion. it is not initiating a sample sequence.

Try building a simple sketch using this code:

uint32_t startTime=millis();
Serial.printf("Starting conversion Cycle at %u\n",startTime);
Wire.beginTransmission(0x77);
Wire.write(0x48); // initial pressure conversion 
Wire.endTransmission();
if(Wire.lastError()!=0){
  Serial.printf("Conversion command Failed =%d\n",Wire.lastError());
  }
else {
  // conversion can take up to 9ms 
// test conversion complete using NAK polling, may not work with this device?
  uint32_t timeout=millis();
  bool ready=false;
  uin32_t reading=0;
  while(!ready && (millis()-timeout<10ms)){
    Wire.beginTransmission(0x77);
    Wire.write(0);
    ready = (Wire.endTransmission()==0);
    if(!ready) Serial.print('.');
    else Serial.println('+');
    }
/* // if NAK polling doesn't work, then use a fixed timeout
  while(millis()-startTime<10); // run in circles shouting 'Please Work'
  ready=true;
*/
// if device ACK'd then it is listening. So ask for data.
  If(ready){
    Wire.requestFrom(0x77,3);
    if(Wire.lastError==0){
      while(Wire.available){
        reading = reading << 8;
        reading = reading + Wire.read();
        }
     uint32_t endTime=millis();
     Serial.printf(" completed conversion cycle  at %u, duration =%d, value =%d\n",endTime,(endTime-startTime),reading);
      }
    else {
      Serial.printf("Read of pressure sensor failed (%u)=%s\n",Wire.lastError(),Wire.getErrorText(Wire.lastError())));
      }
    }
  else {
    Serial.printf("Sensor did not finish conversion within 10ms");
  }
}

this should not generate any timeouts.

The datasheet does not explicitly state that it will honor NAK busy polling. Most I2C devices will. The standard is to do a Write sequence to test the NAK (ready) state. I have never used READ(requestFrom) to test a ready state.

Chuck.

[ifrew]

Thanks for that Chuck. I had only showed the reading part of the sensor code to show the endtransmission(false) part. The full code does trigger pressure and temp samples alternatively with 10ms delays between so it can read the data properly . However, doesn't do any ready checking like you have above. I get spurious readings every so often and it may be due to that. I will look to modify accordingly. Thanks for all your input on this. Much appreciated!

[rrobinet]

Hi, I use a BME280E connected with I2C on a Wemos Lolin 32 and I am regularly losing the connection with the BME module. Currently the only solution I have is to reboot the Wemos. Is there a final solution for this issue or should I better connect it via SPI.

Thanks Robert

[stickbreaker]

@rrobinet are you using my fork stickbreaker/arduino-esp32 or the official fork (this one)?

If you are not using my fork, try it. My fork is a revision to implement I2C reliably.

Chuck.

[rrobinet]

Thanks Chuck, I am loading it now and will see if its is more stable Robert

[rrobinet]

@stickbreaker Hi Chuck, Any idea when this version will be incorporated in the official set? Robert