I2C Rewrite Success or Failure?

[stickbreaker]

I would like everyone that has tried or is going to try my I2C ReWrite to describe their Success(hopefully) or Failures. Also a list of Hardware used and tried would be helpful.

Chuck.
Success 😀 Wemos bluetooth & battery, 24LCxx, DS1307, MCP23008

@lonerzzz has discovered a weakness:

• If Wifi has an authentication failure and I2C is used in a standalone Task it fails.
  • @lonerzzz discovered that pinning the I2C task to Core1 will solve this problem. He theorizes the WiFi is starving the ISR because it has a higher priority.

[andrewradke]

Success with TSL2561, SSD1306 and PCF8523 all on one ESP32.
During startup all three are initialised first, then WiFi.begin() is called, and finally a separate task pinned to core 1 is created to perform all further the I2C operations.

Up until WiFi.status() == WL_CONNECTED I'm getting error code 3 (timeout) on I2C operations. So pinning to core 1 hasn't helped, but all my other errors (primarily bus busy) have vanished.

[lonerzzz]

Success with ESP-WROOM-32 and XMC1300/XMC1100 communicaiton.

@andrewradke If you don't pin the I2C task do you get more errors or the same? I am curious if pinning the I2C task helped you at all.

[andrewradke]

Just tested that and it failed without pinning to core 1, at least for the TSL2561 which reads multiple times a second. After WiFi connected it returned incorrect data for a for about 10 readings, then error code 4 (bus error) once and finally timeouts continuously.

[stickbreaker]

@andrewradke , I just made a new branch NoYield, It just comments out the portYIELD_FROM_ISR() calls in the ISR. Try commenting them out in
/cores/eps32/esp32-hal-i2c.c
lines:
1269,1275,1329,1334,1375,1384,1436

Chuck.

[andrewradke]

I just tried this and left the task unpinned and it fails again. But I think it probably isn't your I2C implementation that's at fault now.

I have another task running a 12 pixel WS2812 LED ring which might be creating enough timing issues that the I2C task collapses if they are on the same core. The LED task is being run through the RMT interface so it uses a hardware buffer but I have the task set at a higher priority to achieve smooth transitions. If I can I'll confirm this sometime later this week.

As it is now with the yields still in place and pinned to core 1 it's been running without a single error for over 24 hours. Before this it would run into an error within a few minutes and stop altogether with 10-15 minutes so I'm very happy.

[stickbreaker]

@andrewradke I have been working another priority/starvation issue #834 with @jlhavens, we have found that the EventGroup calls I am using to synchronize between the ISR and the dispatcher (i2cProcessQueue) are failing. In his case I believe it was the WiFi initialization/authentication that was not sharing.

I had to institute a work-a-round to handle the case where the ISR could not notify the Dispatcher it was complete. This Error caused the Dispatcher to generate a Gross Timeout. This temp patch is in patch1. The only file changed was esp32-hal-i2c.c.

You might try it and see if it changes the pinning requirement.

Chuck.

[stickbreaker]

I'm going to close this one, It has been a success to all that have used it. So my question was answered.

Chuck.