search

espressif / arduino-esp32

Arduino core for the ESP32
GNU Lesser General Public License v2.1
13.3k stars 7.35k forks source link

[ESP32] I2C Interrupt problem since uprade to Espressif 1.1.0 #1588

Closed cyberman54 closed 5 years ago

cyberman54 commented 6 years ago

I'm using u8x8 on ESP32 boards, programmed with Arduino Espressif32 core. I2C display handling using driver U8X8_SSD1306_128X64_NONAME_HW_I2C

This worked perfectly until last days the Espressif32 core was updated from v1.0.2 to v1.1.0.

Since then i get this error during runtime: [E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject int=0x0, ena=0x0

And the display write speed is significantly reduced.

I'm not sure if this is a problem with u8x8 or the Espressif32 core. I'm not using any other I2C communication on the board.

Cross reference to u8x8: https://github.com/olikraus/u8g2/issues/646#issuecomment-402372457

cyberman54 commented 6 years ago

Wrong assignment, re-opened this issue at https://github.com/platformio/platform-espressif32/issues/107

cyberman54 commented 6 years ago

Platformio owner pointed me back to here, so i reopen this issue here.

stickbreaker commented 6 years ago

@cyberman54 I just answered your issue on the platformio repo 107 updating to the newest core will solve most of that error message. The 'injection' error has only been caused by overlapping multi-task use of Wire() review your code to verify that all access to Wire() are single-threaded.

Chuck.

cyberman54 commented 6 years ago

@stickbreaker Problem with the confusing debug messages is now solved, thanks to your pull request. But it still have the problem with the interrupt injections with Espressif32 core 1.1.x, while the same code on the same device runs with Espressif32 core 1.0.2 without this problem.

stickbreaker commented 6 years ago

@cyberman54 the injection error is showing that the ISR was call, but the control structure was not configured for operation, there is a stage variable that has three possible values, STARTUP, RUNNING, and DONE. as you can see by the debug message, it's value was DONE. so the ISR should not have be triggered. Stage is set to done in three places of my code.

Of these three sections of code, the first one was the source I traced down when Wire() was call by multiple tasks in a 'Ardunio' as Component under IDF, the MUTEX was disabled when Arduino is used as a component.

I cannot imagine how the second could result in an injection event. (it happens during interrupt context)

The Third could only happen if the timeout expired, the foreground task started cleaning up the timeout, but before it output the log messages of the failure (Gross timeout, Bus Busy) an i2c interrupt triggered. I cannot see this happening: here is the code. The interrupt would have to trigger before int_ena.val=0 but after stage=I2C_DONE. Well, It couldn't because it would have had to trigger after the int_ena.val=0 for 0x00 to be shown in the debug message. But int_ena controls the hardware interrupt generation. If it is cleared, no hardware interrupt can be generated by the i2c peripheral. I'm confused. Something else is happening. My best guess is multi-tasking of Wire()

    } else { // GROSS timeout, shutdown ISR , report Timeout
        i2c->stage = I2C_DONE;
        i2c->dev->int_ena.val =0;
        i2c->dev->int_clr.val = 0x1FFF;
        if((i2c->queuePos==0)&&(i2c->byteCnt==0)) { // Bus Busy no bytes Moved
            reason = I2C_ERROR_BUSY;
            eBits = eBits | EVENT_ERROR_BUS_BUSY|EVENT_ERROR|EVENT_DONE;
#if ARDUHAL_LOG_LEVEL >= ARDUHAL_LOG_LEVEL_ERROR
            log_e(" Busy Timeout start=0x%x, end=0x%x, =%d, max=%d error=%d",tBefore,tAfter,(tAfter-tBefore),ticksTimeOut,i2c->error);
            i2cDumpI2c(i2c);
            i2cDumpInts(i2c->num);
#endif
        } else { // just a timeout, some data made it out or in.
            reason = I2C_ERROR_TIMEOUT;
            eBits = eBits | EVENT_ERROR_TIMEOUT|EVENT_ERROR|EVENT_DONE;

#if ARDUHAL_LOG_LEVEL >= ARDUHAL_LOG_LEVEL_ERROR
            log_e(" Gross Timeout Dead start=0x%x, end=0x%x, =%d, max=%d error=%d",tBefore,tAfter,(tAfter-tBefore),ticksTimeOut,i2c->error);
            i2cDumpI2c(i2c);
            i2cDumpInts(i2c->num);
#endif
        }
    }

Code that generated the Debug message "injection":

// sync between dispatch(i2cProcQueue) and worker(i2c_isr_handler_default)
typedef enum {
    //I2C_NONE=0,
    I2C_STARTUP=1,
    I2C_RUNNING,
    I2C_DONE
} I2C_STAGE_t;

    if(p_i2c->stage==I2C_DONE) { //get Out
        log_e("eject int=%p, ena=%p",activeInt,p_i2c->dev->int_ena.val);
        p_i2c->dev->int_ena.val = 0;
        p_i2c->dev->int_clr.val = activeInt; //0x1FFF;
        return;
}

As you can see this if() will only trigger if state==I2C_DONE. The only time I have seen this happen was when Wire() was called by multiple task simultaneously. The two hex value printed in the message show the interrupt that generated this call NONE, and the interrupts that are enabled to trigger this ISR NONE. This only happens when code to clear / disable interrupts is called during an active interrupt cycle.

I don't have a clue how the ISR was called out of sequence.

Chuck.

cyberman54 commented 6 years ago

Hmm, sounds difficult. As my application code runs under espressif32 v1.0.2 without this i2c problem, i assume that this behaviour is caused by something that came in by upgrade Espressif32 to v1.1.x.

In my application code i don't use Wire() directly. But i am using u8g2 library to control an OLED I2C display. The author of u8g2 pointed out, that his library is using Wire.h in Arduino style.

My application uses RTos tasks, but u8g2 calls are centralized in one main task. But the main task will be interrupted by other tasks (which don't call Wire()).

stickbreaker commented 6 years ago

@cyberman54 are you using ANY other i2c code? mixing IDF i2c and Arduino i2c?

Chuck.

cyberman54 commented 6 years ago

No. Only I2C component is the OLED display, controlled by u8g2 library.

bartoszbielawski commented 6 years ago

I have exactly the same problem. One I2C display that is controlled from a separate FreeRTOS task. The class for the display does something and from the same thread I change Wire pin assignments and speed. Otherwise no other accesses.

stickbreaker commented 6 years ago

@cyberman54 @bartoszbielawski are you both using Platformio? I use Arduino. Can either or both of you make a small /simple example that shows this problem?

If I need to set up a Platformio environment I will, but I will probably need some help :grin:

Chuck.

cyberman54 commented 6 years ago

Chuck, you may just look to my repo:

https://github.com/cyberman54/ESP32-Paxcounter/tree/development?files=1

bartoszbielawski commented 6 years ago

@stickbreaker Yes, I use PIO as well. I have already written a minimal test program and I think it should be easy to run it in Arduino IDE: https://gist.github.com/bartoszbielawski/bf9a03d6eb505b299c7fd6a8b641021c

The screen itself has some extra random dots and the printed number sometime jump few pixels back and forth + the error messages - check the end of the gist.

stickbreaker commented 6 years ago

@bartoszbielawski try changing the xTaskCreate to:


void setup() 
{
    Serial.begin(115200);
    xTaskCreatePinnedToCore(displayThread, "DT", 8192, NULL, 5, NULL,1);    
}

You are starting this task at priority 5, the basic Arduino loop runs at 1. And possibly the interrupt is triggering on the wrong core?

Chuck.

stickbreaker commented 6 years ago

@bartoszbielawski can you make a change in cores\exp32\p32-hal-i2c.c about line 593

   if(p_i2c->stage==I2C_DONE) { //get Out
        log_e("eject int=%p, ena=%p core=%d",activeInt,p_i2c->dev->int_ena.va,xPortGetCoreID());
        p_i2c->dev->int_ena.val = 0;
        p_i2c->dev->int_clr.val = activeInt; //0x1FFF;
        return;
}

Changing the log_e() line to add the coreID.

Chuck.

bartoszbielawski commented 6 years ago

@stickbreaker Okay, I have done some tests and here are my conclusions:

  1. it doesn't matter on which code the task runs - I tested it both on core 0 and core 1, the error message always comes from the corresponding core.
  2. (clock rate <= 400 kHz) or (priority == 0) fixes the problem.
  3. For clock rates >= 400 kHz (tested with 800 kHz) priority == 0 helps but the bus is very slow.

I guess I will reduce I2C speed to the regular 400 kHz. Does it mean that in some cases (clocks >= 400 kHz) the result arrives faster than the software expects it?

stickbreaker commented 6 years ago

@bartoszbielawski let me think about this. So, when you pin it to core1 the Eject says core=1 and if you pin it to core0, eject says core=0.

I have ran my test bed that has 10 i2c devices on a 18" bus at 1,000,000hz for 10k+ operations. But I haven't tried from a separate task, just the prime arduino core.

No, the ISR responds to the interrupts, if they are slower it just takes longer. The ISR is designed to handle concurrent interrupts. the ESP32 won't dispatch while it is in an interrupt.

The Stage==Done is saying Either it completed or a Timeout happened.

another change: add debug code to display the prior interrupt list:

    if(p_i2c->stage==I2C_DONE) { //get Out
        log_e("eject int=%p, ena=%p",activeInt,p_i2c->dev->int_ena.val);
        i2cDumpInts(p_i2c->num);
        p_i2c->dev->int_ena.val = 0;
        p_i2c->dev->int_clr.val = activeInt; //0x1FFF;
        return;

Chuck

cyberman54 commented 6 years ago

@stickbreaker I added both of your above debug modifications to esp32-hal-i2c.c and i'm getting this result:

[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject int=0x0, ena=0x0
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x000001ad
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x000001ad
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x000001ae
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x000001ae
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject int=0x0, ena=0x0
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x00000e80
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x00000e80
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x00000e81
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x00000e81
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject int=0x0, ena=0x0
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x00000ed0
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x00000ed0
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x00000ed1
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x00000ed1
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject int=0x0, ena=0x0
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x000022ca
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x000022ca
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x000022cb
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x000022cb
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject int=0x0, ena=0x0
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x000a 0x0000 0x000022ec
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x000022ec
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x000a 0x0040 0x0000 0x0000 0x000022ed
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x000022ed
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject int=0x0, ena=0x0
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x000a 0x0000 0x0000232f
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x0000232f
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x000a 0x0040 0x0000 0x0000 0x00002330
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x00002330
cyberman54 commented 6 years ago

sorry, i forgot the core=%d in the log statement, here we go again:


[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject int=0x0, ena=0x0, core=1
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x000a 0x0000 0x000001bd
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x000001bd
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x000a 0x0040 0x0000 0x0000 0x000001be
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x000001be
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject int=0x0, ena=0x0, core=1
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x000a 0x0000 0x000001df
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x000001df
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x000a 0x0040 0x0000 0x0000 0x000001e0
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x000001e0
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject int=0x0, ena=0x0, core=1
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x000a 0x0000 0x00000218
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x00000218
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x000a 0x0040 0x0000 0x0000 0x00000219
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x00000219
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject int=0x0, ena=0x0, core=1
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x000a 0x0000 0x00000244
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x00000244
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x000a 0x0040 0x0000 0x0000 0x00000245
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x00000245
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject int=0x0, ena=0x0, core=1
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x000a 0x0000 0x00000287
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x00000287
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x000a 0x0040 0x0000 0x0000 0x00000288
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x00000288
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject int=0x0, ena=0x0, core=1
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x000002c8
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x000002c8
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x000002c9
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x000002c9
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject int=0x0, ena=0x0, core=1
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x0000233c
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x0000233c
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x0000233d
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x0000233d

So, code runs on core1. This is as expected, since i control the i2c display from arduino main loop, and this runs on core1 with RTos.

cyberman54 commented 6 years ago

And after some seconds i get a Guru Meditation Error:

[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject int=0x0, ena=0x0, core=1
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x000a 0x0000 0x000030a7
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x000030a7
[D]Guru Meditation Error: Core  1 panic'ed (Interrupt wdt timeout on CPU1)
Core 1 register dump:
PC      : 0x40094a96  PS      : 0x00060534  A0      : 0x80092636  A1      : 0x3ffc0ac0
A2      : 0x3ffd6590  A3      : 0x3ffd8784  A4      : 0x00000001  A5      : 0x00000001
A6      : 0x00060523  A7      : 0x00000000  A8      : 0x3ffd8784  A9      : 0x3ffd8784
A10     : 0x00000019  A11     : 0x00000019  A12     : 0x00000001  A13     : 0x00000001
A14     : 0x00060521  A15     : 0x00000000  SAR     : 0x00000004  EXCCAUSE: 0x00000006
EXCVADDR: 0x00000000  LBEG    : 0x400014fd  LEND    : 0x4000150d  LCOUNT  : 0xfffffffc
Core 1 was running in ISR context:
EPC1    : 0x4000beb4  EPC2    : 0x00000000  EPC3    : 0x4000921a  EPC4    : 0x40094a96

Backtrace: 0x40094a96:0x3ffc0ac0 0x40092633:0x3ffc0ae0 0x400911f7:0x3ffc0b00 0x400d78d0:0x3ffc0b40 0x4018eb2f:0x3ffc0ba0 0x4008638e:0x3ffc0be0 0x400819dd:0x3ffc0c10 0x401b929f:0x00000000

Core 0 register dump:
PC      : 0x40091bde  PS      : 0x00060034  A0      : 0x800922fb  A1      : 0x3ffc0590
A2      : 0x3ffc28d0  A3      : 0x0000cdcd  A4      : 0xb33fffff  A5      : 0x00000001
A6      : 0x00060021  A7      : 0x0000abab  A8      : 0x0000abab  A9      : 0x3ffc0590
A10     : 0x00000003  A11     : 0x00060023  A12     : 0x00060021  A13     : 0x3ffc64c8
A14     : 0x0000002a  A15     : 0x3ffdd8e0  SAR     : 0x00000015  EXCCAUSE: 0x00000006
EXCVADDR: 0x00000000  LBEG    : 0x400014fd  LEND    : 0x4000150d  LCOUNT  : 0xfffffffd

Backtrace: 0x40091bde:0x3ffc0590 0x400922f8:0x3ffc05c0 0x40093487:0x3ffc05e0 0x4009318d:0x3ffc0600 0x400819e6:0x3ffc0610 0x40009217:0x00000000

The dump resolves to:


Decoding 23 results
0x40094a96: vListInsert at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/list.c line 188
0x40094a96: vListInsert at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/list.c line 188
0x40094a96: vListInsert at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/list.c line 188
0x40092633: vTaskPlaceOnEventList at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/tasks.c line 3564
0x400911f7: xQueueGenericReceive at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/queue.c line 2520
0x400d78d0: log_printf at ?? line ?
0x4018eb2f: i2cDumpInts at ?? line ?
0x4008638e: i2c_isr_handler_default at esp32-hal-i2c.c line ?
0x400819dd: _xt_lowint1 at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/xtensa_vectors.S line 1105
0x401b929f: esp_vApplicationWaitiHook at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/freertos_hooks.c line 66
0x40091bde: uxPortCompareSet at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/tasks.c line 3564
:  (inlined by) vPortCPUAcquireMutexIntsDisabledInternal at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/portmux_impl.inc.h line 86
:  (inlined by) vPortCPUAcquireMutexIntsDisabled at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/portmux_impl.h line 98
:  (inlined by) vTaskEnterCritical at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/tasks.c line 4254
0x40091bde: uxPortCompareSet at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/tasks.c line 3564
:  (inlined by) vPortCPUAcquireMutexIntsDisabledInternal at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/portmux_impl.inc.h line 86
:  (inlined by) vPortCPUAcquireMutexIntsDisabled at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/portmux_impl.h line 98
:  (inlined by) vTaskEnterCritical at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/tasks.c line 4254
0x400922f8: xTaskIncrementTick at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/tasks.c line 3564
0x40093487: xPortSysTickHandler at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/port.c line 326 (discriminator 1)
0x4009318d: _frxt_timer_int at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/portasm.S line 303
0x400819e6: _xt_lowint1 at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/xtensa_vectors.S line 1105
stickbreaker commented 6 years ago

@bartoszbielawski

[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject int=0x0, ena=0x0 [E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row count INTR TX RX [E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x000001ad [E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x000001ad [E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x000001ae [E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x000001ae

That is weird, nothing is showing up a wrong, just that you are seeing a unserviced interrupt. That shows a total of 6 interrupts, a TxFifoEmpty, StartTransaction, 3 bytes moved, EndTransaction.

More Debug, lets see the time frame between the last interrupt and this spurious interrupt.

    if(p_i2c->stage==I2C_DONE) { //get Out
        log_e("eject tick=0x%8x int=%p, ena=%p core=%d", xTaskGetTickCountFromISR(),activeInt,p_i2c->dev->int_ena.val,xPortGetCoreID());
        i2cDumpInts(p_i2c->num);
        p_i2c->dev->int_ena.val = 0;
        p_i2c->dev->int_clr.val = activeInt; //0x1FFF;
        return;

Chuck

stickbreaker commented 6 years ago

@bartoszbielawski ignore the core dump, too much debug output during an interrupt, Watchdog died of starvation.

bartoszbielawski commented 6 years ago

Sorry guys, I'm out for today. I have a long drive tomorrow and have to be rested...

Bartosz

stickbreaker commented 6 years ago

@bartoszbielawski Thanks for trying.

Chuck.

cyberman54 commented 6 years ago

i will check tommorow.

stickbreaker commented 6 years ago

@bartoszbielawski Thru more research we might be having a pullup problem. if this is your board Heltec WiFi kit 32 It shows only 10k pullups on the SDA and SCL lines. Try adding 3.3k pullups. That should drop the effective pullups to 2.3k. We might be having pullup issues at higher data rates.

Chuck.

cyberman54 commented 6 years ago

@bartoszbielawski does is work with Espressif32 v1.0.2 and same.board?

@stickbreaker SDA/SCL are muxed in the ESP32 and can be switched to different GPIOs

bartoszbielawski commented 6 years ago

@cyberman54 It does work on 1.0.2 on the same board. @stickbreaker I could understand the problem happens due to weak pull-ups but how does setting priority of the task to 0 fix the problem? I'm willing to tinker with the board but I don't have access to my lab at the moment.

stickbreaker commented 6 years ago

@bartoszbielawski It looks like we are running into some kind of race condition. the pullup will change the performance of the i2c transmission. The i2c peripheral measures signal level after the waveform voltage reaches a trigger voltage. With High data rates and weak pullups cause a very unsymmetrical waveform. Electrically I know 10k is too weak for any clock rate above 100kHz at 3.3v. I wrote a article in my repo's wiki about pullup value considerations if you are interested.

Another debug change you can do, change the 'inject' of show the raw interrupt value instead of the filtered one:

   if(p_i2c->stage==I2C_DONE) { //get Out
        log_e("eject tick=0x%8x rawint=%p, ena=%p core=%d", xTaskGetTickCountFromISR(), p_i2c->dev->int_raw.val, p_i2c->dev->int_ena.val,xPortGetCoreID());
        i2cDumpInts(p_i2c->num);
        p_i2c->dev->int_ena.val = 0;
        p_i2c->dev->int_clr.val = activeInt; //0x1FFF;
        return;

Chuck.

cyberman54 commented 6 years ago

@stickbreaker Here's my output logging the raw interrupts:

[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject tick=0x     1da rawint=0x2, ena=0x0 core=1
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x000001d9
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x000001d9
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x000001da
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x000001da
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject tick=0x     23f rawint=0x2, ena=0x0 core=1
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x0000023e
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x0000023e
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x0000023f
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x0000023f
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject tick=0x     275 rawint=0x2, ena=0x0 core=1
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x00000274
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x00000274
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x00000275
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x00000275
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject tick=0x     8b8 rawint=0x2, ena=0x0 core=1
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x000008b7
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x000008b7
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x000008b8
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x000008b8
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject tick=0x     eec rawint=0x2, ena=0x0 core=1
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x00000eeb
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x00000eeb
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x00000eec
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x00000eec
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject tick=0x     f5a rawint=0x2, ena=0x0 core=1
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x000a 0x0000 0x00000f59
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x00000f59
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x000a 0x0040 0x0000 0x0000 0x00000f5a
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x00000f5a
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject tick=0x    233c rawint=0x2, ena=0x0 core=1
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x000a 0x0000 0x0000233b
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x0000233b
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x000a 0x0040 0x0000 0x0000 0x0000233c
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x0000233c
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject tick=0x    2374 rawint=0x2, ena=0x0 core=1
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x00002374
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x00002374
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x00002374
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x00002374
[E][esp32-hal-i2c.c:594] i2c_isr_handler_default(): eject tick=0x    23a3 rawint=0x2, ena=0x0 core=1
[E][esp32-hal-i2c.c:1438] i2cDumpInts(): 0 row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [01] 0x0001 0x0002 0x0003 0x0000 0x000023a2
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x000023a2
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [03] 0x0003 0x0040 0x0000 0x0000 0x000023a3
[E][esp32-hal-i2c.c:1442] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0000 0x000023a3
bartoszbielawski commented 6 years ago

Yeah, I get the problem we could have with the pullups but why would setting task priority to 0 solve the problem? The HW I2C would be still sending data at the fixed (high speed)...

2018-07-09 1:29 GMT+02:00 chuck todd notifications@github.com:

@bartoszbielawski https://github.com/bartoszbielawski Thru more research we might be having a pullup problem. if this is your board Heltec WiFi kit 32 https://github.com/Heltec-Aaron-Lee/WiFi_Kit_series/blob/master/SchematicDiagram/WIFI_Kit_32_Schematic_diagram.PDF It shows only 10k pullups on the SDA and SCL lines. Try adding 3.3k pullups. That should drop the effective pullups to 2.3k. We might be having pullup issues at higher data rates.

Chuck.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/1588#issuecomment-403325679, or mute the thread https://github.com/notifications/unsubscribe-auth/AD2sEP16WSsWbjncQBzM5oWh3cJq0pIeks5uEpXugaJpZM4VCBhO .

cyberman54 commented 6 years ago

@bartoszbielawski if this issue is caused by a race condition, i think it depends on the individual application environment if and what sort of influence task priorities have on interrupts. In my application it makes no difference if i run the main task (which controls a i2c display) on core 1 with prio 0 or prio 1, in both cases the error occurs.

In my opinion the question is: why didn't this happen with Espressif32 1.0.2 core? Regardless of dimensions of pullups. Because the same hardware with same pullups now with Espressif32 1.1.x triggers the error.

cyberman54 commented 6 years ago

I checked the schematic of the board i am using for above tests, a TTGO ESP32 v2.1. This board uses GPIO21 (SDL) and GPIO22 (SCLK) of ESP32 for i2c bus. Each pin is tied with a 4,7k ohm pullup to Vcc.

stickbreaker commented 6 years ago

@bartoszbielawski @cyberman54 the Raw 0x2 is a TxFifo empty, which is a true interrupt. The Tx Fifo is empty, but i'll have to look at the STOP interrupt handling. I need to verify the order that I shut down the peripheral when the end of the command queue is reached. I might have to stuff a few null bytes into the txFifo to prevent this interrupt. These null bytes wouldn't cause any problem, because when I setup for the next transaction the first thing I do is reset the Fifo's. These null bytes will never exit the peripheral because the peripheral command buffer includes the number of bytes to move, this number of bytes is detached from the fill level of the fifo, if I tell it to send 5 bytes, but only put 4 bytes in the fifo, the fifth byte sent is 0xff.

The 4.7k pulls will work with 100kHz, but I would measure the signal to calculate the bus capacitance before I increased speed. With 4.7k to 3.3v the drive current is only 0.702mA, I like 1 ~ 1.5mA. Standard I2C devices usually spec a 3mA max drive. With 2.4k I get a 1.375mA. With a 5v i2c 4.7k gives 1.064mA.

I'll do some testing to see how the TxFifo empty could be generating an interrupt after/during the STOP. Normally, the txFifo is filled with all available out bound characters or 32(fifo max). If all characters will fit in fifo, the txEmpty interrupt is disabled. We could be having a Read/Modify/Update problem with the int_ena register.

That new debug output is showing the spurious interrupt is being generated just after the 0x80 (STOP).

I'll see if I can regenerate this problem tomorrow.

Chuck.

stickbreaker commented 6 years ago

@bartoszbielawski @cyberman54 What Exact ESP32 board are you using? I don't have one with a SSD1306 display, I might have to purchase one to test.

Chuck.

cyberman54 commented 6 years ago

i tested the issue with different ESP32 LoRa OLED boards, all show same error:- Heltec Wifi Lora Kit32- TTGO T3 v2.1 (4k7 pullups)- TTGO T3 v2Am 10.07.2018 05:41 schrieb chuck todd notifications@github.com:@bartoszbielawski @cyberman54 What Exact ESP32 board are you using? I don't have one with a SSD1306 display, I might have to purchase one to test. Chuck.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

bartoszbielawski commented 6 years ago

@cyberman54 I have Heltec without LoRa. That one has SSD1306 (128x64). For the resistors I agree. I could measure it myself but I left for looong holidays and ESP32 board to carry with me is fine but a scope is not ;)

2018-07-10 5:41 GMT+02:00 chuck todd notifications@github.com:

@bartoszbielawski https://github.com/bartoszbielawski @cyberman54 https://github.com/cyberman54 What Exact ESP32 board are you using? I don't have one with a SSD1306 display, I might have to purchase one to test.

Chuck.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/1588#issuecomment-403690304, or mute the thread https://github.com/notifications/unsubscribe-auth/AD2sEAxmXYOrh7517elRIOGzoTZ-FLXIks5uFCJ6gaJpZM4VCBhO .

cyberman54 commented 6 years ago

@stickbreaker if this helps, i can express air mail you a test board (Heltec) which shows the issue.

stickbreaker commented 6 years ago

@cyberman54 sure, I have found them on BangGood 7~20 day delivery. That would probably speed up my fix. I'll send you and email with my address.

Chuck.

cyberman54 commented 6 years ago

@stickbreaker Got it. Tomorrow by 8 PM the postman will hand over a gift with 1 piece Heltec Lora 32 board with i2c OLED to you.

stickbreaker commented 6 years ago

@cyberman54 Thanks, I've been looking at the adafruit ssd1306 code, I can see where I think I can dramatically speed it up.

With the new Wire() code, a screen refresh can happen with one i2c call. It will require a slight change to the SSD1306 screen buffer. I'll have to add one byte at the beginning of the buffer, It will be fun to see if my idea works.

Currently the SSD1306 code sends 16byte blocks of the screen at a time. So a full refresh takes 64 loops. each loop is built one byte at a time with all the buffer position, bounds checking, data copying. By changing the screen buffer, and using different Wire() commands one function calls should suffice.

  //@stickBreaker for big blocks and ISR model
    i2c_err_t writeTransmission(uint16_t address, uint8_t* buff, uint16_t size, bool sendStop=true);
    i2c_err_t readTransmission(uint16_t address, uint8_t* buff, uint16_t size, bool sendStop=true, uint32_t *readCount=NULL);

This code from AdaFruits SSD1306

 {
    // save I2C bitrate
#ifdef TWBR
    uint8_t twbrbackup = TWBR;
    TWBR = 12; // upgrade to 400KHz!
#endif

    //Serial.println(TWBR, DEC);
    //Serial.println(TWSR & 0x3, DEC);

    // I2C
    for (uint16_t i=0; i<(SSD1306_LCDWIDTH*SSD1306_LCDHEIGHT/8); i++) {
      // send a bunch of data in one xmission
      Wire.beginTransmission(_i2caddr);
      WIRE_WRITE(0x40);
      for (uint8_t x=0; x<16; x++) {
        WIRE_WRITE(buffer[i]);
        i++;
      }
      i--;
      Wire.endTransmission();
    }
#ifdef TWBR
    TWBR = twbrbackup;
#endif
  }
}

Becomes this under ESP32

uint32_t oldClock = Wire.getClock();
Wire.setClock(400000);

i2c_err_t err=Wire.writeTransmission(_i2cAddress, buffer,(SSD1306_LCDWIDTH*SSD1306_LCDHEIGHT/8)+1);
if(err != I2C_ERROR_OK){ // say what went wrong
  log_e("Screen Update Failed =%d %s",err,Wire.getErrorText(err));
}

Wire.setClock(oldClock);

There is a net saving of 30 transmitted bytes also. Only one i2c block( one _i2cAddress, one Command/data byte)

It might also be possible to increase performance of the command calls.

Well, hopefully I will see the 'injection' errors tomorrow with the original library code, after I solve that problem, it should be fun to see if these potential optimizations are valuable.

Chuck.

cyberman54 commented 6 years ago

Still the question what is the root cause and why did it not happen with Espressif32 1.0.2?

stickbreaker commented 6 years ago

@cyberman54 I think the issue is going to be a change in interrupt allocation. I don't know how deep I am going to have to dive. I've got some Idea where to look, It could be a Shared interrupt issue( I allocate the interrupt as Edge with isn't allowed when using a Shared interrupt.) I don't specifically ask for a Shared interrupt, and by specifying Edge triggering it should not assign it to a Shared interrupt, Maybe something changed. Or it could be that an interrupt was added to the dispatcher queue before the code disabled interrupts. I might need to prevent an interrupt instead of masking it. Or it could be the order of execution inside the ISR. I found that I need to specifically order the sequence for servicing simultaneous interrupts. When I can recreate the errors I will have a path to follow to fix them.

I have been working on some new code to increase performance by no longer needing process each byte with I2C_MASTER_TRAN_COMP_INT_ST interrupts. this should really reduce load on the CPU. the ISR code will only be invoked on START, STOP, FifoEmpty/Full or errors.

Chuck.

dpharris commented 6 years ago

Thank you for you ongoing work for us all! Kudos.

David

On Tue, Jul 10, 2018, 15:03 chuck todd notifications@github.com wrote:

@cyberman54 https://github.com/cyberman54 I think the issue is going to be a change in interrupt allocation. I don't know how deep I am going to have to dive. I've got some Idea where to look, It could be a Shared interrupt issue( I allocate the interrupt as Edge with isn't allowed when using a Shared interrupt.) I don't specifically ask for a Shared interrupt, and by specifying Edge triggering it should not assign it to a Shared interrupt, Maybe something changed. Or it could be that an interrupt was added to the dispatcher queue before the code disabled interrupts. I might need to prevent an interrupt instead of masking it. Or it could be the order of execution inside the ISR. I found that I need to specifically order the sequence for servicing simultaneous interrupts. When I can recreate the errors I will have a path to follow to fix them.

I have been working on some new code to increase performance by no longer needing process each byte with I2C_MASTER_TRAN_COMP_INT_ST interrupts. this should really reduce load on the CPU. the ISR code will only be invoked on START, STOP, FifoEmpty/Full or errors.

Chuck.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/1588#issuecomment-403980837, or mute the thread https://github.com/notifications/unsubscribe-auth/AAg4SuqpXz9tM4oZx1S8mbzdsXLhW-pyks5uFSTOgaJpZM4VCBhO .

stickbreaker commented 6 years ago

@cyberman54 Received it. and It booted. So, now to see if I can make it fail.

Chuck.

cyberman54 commented 6 years ago

@stickbreaker for quick & dirty 1st test you may just compile my RTos based application code, flash it and open serial console, then you see the i2c error log and the corresponding esp_calls

https://github.com/cyberman54/ESP32-Paxcounter

stickbreaker commented 6 years ago

@cyberman54 I was able to regenerate the eject error.

Also, the AdaFruit ssd1306 lib does not do any error checking. I have been getting ACK errors during the command sequence calls. That is what is messing up the display, some of the commands are not being accepted by the display.

I did not get eject command until i increased the clock rate from 100k to 400k.

so, now I have something to find. :grinning:

Chuck.

stickbreaker commented 6 years ago

@cyberman54 Definitely speed related, 375000Hz does not cause any 'eject', 500kHz continous.

stickbreaker commented 6 years ago

@cyberman54 625kHz works with no i2c errors, but the Display is having a hard time.

bartoszbielawski commented 6 years ago

On 1.0.2 it was working fine for me at 800 kHz, no I2C error, no problems with the display.

cyberman54 commented 6 years ago

@stickbreaker as yet i had no attention on how fast the i2c in my app is operated, because i use only one i2c slave on the bus, and this is the SSD1306 OLED controller which, in my app, is not performance critical.

Now i checked the u8g2 lib code and found this:

https://github.com/olikraus/u8g2/commit/6c81aaab2658341e9cd3708762405223f40ba11e

The clock speed is set to 400 kHz depending on arduino version greaterequal than 1.6.0.

With last Espressif32 core update i think i saw an uplift of arduino 1.5.3 to 1.6.0, which could point to the above piece of code in u8g2.

Result would be that in former development framework display was running on 100khz without problems and after framework update u8g2 switched to 400khz what triggered the injection issue?