DEbug messages when using i2c

[heliophagus]

Please fill the info fields, it helps to get you faster support ;)

If you have a Guru Meditation Error, please decode it:
https://github.com/me-no-dev/EspExceptionDecoder

----------------------------- Remove above -----------------------------

Hardware:

Board: Adafruit ESP32 Feather
Core Installation/update date: ?11/jul/2017?
IDE name: Arduino 1.8.5
Flash Frequency: 80Mhz
Upload Speed: 115200

Description:

Greetings! I'm communicating with a SHT31 and an LPS25 via i2c on the ESP32. Got lots and lots of NaNs until I switched over to Stickbreaker's wire library (thanks, Stickbreaker!). But I keep getting apparent i2c debug messages mixed in with my data stream on the serial monitor. Perhaps 1 every 50 - 200 lines. I tried looking at the source libs but found no Serial.print messages there. Example of the debug message:

[E][esp32-hal-i2c.c:1127] i2cProcQueue(): I2C exitCode=0x112

The core debug level is set to none.

Any idea how to turn these error messages off, or better still, prevent them from happening? Any help would be much appreciated!

HP

[me-no-dev]

with debug level set to none they should not appear... you sure you have set it correctly?

[stickbreaker]

@heliophagus update to the current espressif-arduino, me-no-dev just merged my code. After you update, then if you have any problems we'll fix it.

Chuck.

[heliophagus]

Thanks for the response! I’ll update and report back.

[heliophagus]

Updated, and all looks good so far, though the testing isn't yet complete - I'll wait until I have a few hours of i2c output captured at 10 Hz without the error code.

One weirdness: After programming, I got the message "E (112) spiram: SPI RAM enabled but initialization failed. Bailing out." - but the code appears to work well. Perhaps because I happen not to be using SPI, though that will change, so it's a bit concerning. BTW, I have TOOLS/CORE DEBUG LEVEL set to "None".

[stickbreaker]

@heliophagus The SPI RAM error is generated because the new IDF core includes support for the PSDRAM of the WROVER module. The WROVER adds a SPI PSDRAM to increase the available RAM by 4mB. It uses the FLASH SPI (gpio06..11)+ gpio16 & gpio17. There has been a report of problems with gpio16&17 #1550. These problems could be related to the SPI RAM probe.

Chuck.

[heliophagus]

Interesting about the SPI RAM error - thanks, Stickbreaker.

But, a definite problem with i2c. All works well for a while, about 10-60 minutes, then all readings cease and the data timeout increases 100-fold. On the uploaded graph, green = a variable obtained by calculation from the SHT31 data obtained via i2c, magenta = barometric pressure (nice microbaroms!) via i2c, and grey = time taken to obtain the i2c data. As you can see on the graph (axes not to scale), all i2c data freezes after ~20 min and the i2c timeout simultaneously skyrockets. Restarting the program didn't help. After depowering the ESP32 and the data acquisition board, it works again - for a while. This is actually worse behavior than before, except that I no longer see the debug messages. The fact that the identical setup worked OK with the previous build suggests that the issue is somewhere in the current ESP32 build.

Any ideas...?

[heliophagus]

A bit more information: When this "freezing" happens (which is new to this build), the data line is pulled low. The circuit is attached via a breadboard, so I disconnected the data line to see which side was being pulled low. Both sides measured high. Then I reconnected them and the i2c bus started working again, with normal acquisition times. Maybe this might help with diagnosis?

[stickbreaker]

@heliophagus Describe your electrical circuit, the 112 error is an arbitration error. The ESP32 was sending data out, it sent a high, but the SDA pin stayed low. This generates an arbitration failure.

I just skimmed through the SHT31 datasheet.

Do you know if you are using SCL stretching or NAK synchronization? That sensor is pretty slow, 4 -15ms depending on accuracy, the 'periodic' readings range from 0.5hz to 10hz.

I need more info to guess what is going on, I have tested this code by moving data between multiple 24LCxx EEPROMs. I have a I2C buss with 2.4k pullups, 7 eeproms, 1 RTCC (DS1307) 2 MCP23008 i/o Expanders (20x4 LCD, 4x4 keypad) 1 MPC23017 (24x1 LCD). I have a test that moves an increasing block of data (128bytes to 8192) 128,129,130.. It starts out with a read of 128 bytes, writes 128 (with writepage consideration) then increments the block size by 1 (to 129). The address pointer moves through the 64kB dataspace. Each written block is then verified before the next block.
The EEPROM write cycle timing results in about a 12kBs effective speed, so in a 24hr test writes about 1GB.

Chuck.

[stickbreaker]

@heliophagus I just saw your new post.
Do you have access to the reset pin of the SHT31? The Low on SDA would hang the bus. One of them is driving SDA low.

Describe you circuit. When you disconnected SDA, where were the Pullups? CPU side or Sensor Side?

Chuck.

[stickbreaker]

@heliophagus do you get any error messages? What have you set the Core Debug Level to?

Chuck.

[stickbreaker]

@heliophagus Can you describe you project? is it using Wifi? How are the i2c sensors accessed? (the Wire() does not support multi-thread, or interrupt access)

Chuck.

[heliophagus]

@stickbreaker, pullups are on the sensor side, 10k. No error messages, though I used to get the 112 error occasionally with the previous build. Right now I don't have debug turned on. The code is really simple - at the start I send the SHT31 a reset (0x30A2), wait 10 msec, then regularly initiate a RH&T conversion in high-res mode with no clock stretching (0x2400), wait 20 msec (using a state machine), then retrieve the 6 bytes of data. I do this every 25 msec. If there is a crc error, I send another reset, wait 10 msec, and try again. In the previous build, this cured the problem, but now it doesn't. Unfortunately I haven't wired the hardware reset pin.

This is part of a larger analysis system rather than an end in itself. I'm only testing this one subassembly right now. I'm not using Wifi or multithreading.

Many kudos for helping out with this!

[heliophagus]

Alas, I have to leave town for a long-standing commitment and can't take the device with me, but I've asked the team leader to keep track of this and work on it. I'll be checking back in with him and this thread often.

[stickbreaker]

@heliophagus does your code read the error return codes?

uint8_t err = Wire.endTransmission();
if (err!=0){
  Serial.printf("Wire() Write failed, lastError=%d (%s)\n",Wire.lastError(),Wire.getErrorText(Wire.lastError()));
}
// or
uint8_t count = Wire.requestFrom(SensorAddr,requestCount);
if(count != requestCount){
  Serial.printf("Wire() Read failed, expected %d actually received %d, lastError=%d (%s)\n",
    requestCount,count,Wire.lastError(),Wire.getErrorText(Wire.lastError()));
}

Chuck.

[stickbreaker]

@heliophagus with your 10k pullups I would decrease the clock rate the ESP 32 might be detecting an arbitration fault because the SDA or SCL line has not returned High fast Enough. If you have access to an oscilloscope measure the waveforms. As a software fix, try dropping down to 50kHz or 25kHz.

Wire.setClock(50000); 
//
Wire.setClock(25000);

Chuck.

[heliophagus]

Great suggestion! BTW, am running your suggested code, but typically as dictated by Murphy there have been no errors yet.

[heliophagus]

Alas, I'm outta here... Definitely will scope out the i2c lines and drop the value of the pullups. Thanks again! My team will be back in touch with an update next week.

[stickbreaker]

@heliophagus have a good weekend.

chuck.

[copercini]

Fixed on #1767 =)