busio.I2C issues on ESP32-S3: LC709203F

[kattni]

CircuitPython version

Adafruit CircuitPython 7.3.0-beta.1 on 2022-04-07; Adafruit Feather ESP32S2 with ESP32S2

Code/REPL

import time
import board
import bitbangio
from adafruit_lc709203f import LC709203F, PackSize

i2c = bitbangio.I2C(board.SCL, board.SDA, frequency=250000, timeout=1000000)
battery_monitor = LC709203F(i2c)

battery_monitor.pack_size = PackSize.MAH400

while True:
    print("Battery Percent: {:.2f} %".format(battery_monitor.cell_percent))
    print("Battery Voltage: {:.2f} V".format(battery_monitor.cell_voltage))
    time.sleep(2)

Behavior

Fails on line 9 with the following:

code.py output:
Traceback (most recent call last):
  File "code.py", line 9, in <module>
  File "adafruit_lc709203f.py", line 119, in __init__
  File "adafruit_lc709203f.py", line 164, in power_mode
  File "adafruit_lc709203f.py", line 247, in _write_word
OSError: [Errno 5] Input/output error

Description

frequency and timeout have no effect on the behavior. It was already crashing consistently after a short period of time with busio and board.I2C(), or straight up not seeing the chip (even though I2C scan sees it). So we wanted to try bitbang I2C. bitbangio crashed more quickly than busio did.

After chatting with @dhalbert about it, as per request, I am filing a bug here.

Additional information

No response

[mrdalgaard]

Could this be related?
adafruit/Adafruit_CircuitPython_LC709203F#3
Perhaps try bitbangio with a very low frequency to see if the result is the same as in above bug

[dhalbert]

I cannot reproduce this with busio.I2C() on a Feather ESP32-S2, either with 7.3.0-beta.1 or the pending #6366 I2C fix. busio works fine. It's true that bitbangio gives the error above. I have been running for several minutes during each trial. I tested with only USB, with USB and an attached battery, and with a battery only, sending output to the default UART.

import time
import bitbangio
import board
import busio
from adafruit_lc709203f import LC709203F, PackSize

uart = board.UART()
battery_monitor = LC709203F(board.I2C())

battery_monitor.pack_size = PackSize.MAH400

while True:
    print("Battery Percent: {:.2f} %".format(battery_monitor.cell_percent))
    print("Battery Voltage: {:.2f} V".format(battery_monitor.cell_voltage))

    uart.write(b"Battery Percent: {:.2f} %\r\n".format(battery_monitor.cell_percent))
    uart.write(b"Battery Voltage: {:.2f} V\r\n".format(battery_monitor.cell_voltage))

    time.sleep(2)

[dhalbert]

Tested further. These all work with #6366. Did not try with 7.3.0-beta.1

• old ESP32-S2 Feather (rev A?)
• Rev C ESP32-S2 Feather
• ESP32-S2 Feather TFT

ESP32-S3 Feather works sometimes for a while at 10kHz I2C clock. At 100kHz, seems to fail immediately. Saleae trace with working reads, and then last is failure:
Feather-ESP32-S3-LC709203F-10kHz.sal.zip

[dhalbert]

We are also seeing issues with MCP960x, which does clock stretching and repeated start. Before #6366, I see Input/output error, as above. After #6366, I am more likely to see the sensor not even appear in a scan.

EDIT: MCP960x problem is a sensor problem, not related to this. Fixed for MCP960x by adafruit/Adafruit_CircuitPython_MCP9600#20.

[dhalbert]

For LC709203F, I am seeing bad handling of a clock stretch. The top trace is ESP-S3, the bottom trace is ESP-S2. The first four I2C transactions are the same. Then there is a clock stretch, which works on the S2, but not the S3. Note that SDA goes high after a relatively short time in the top (S3, bad) trace.

[dhalbert]

I am going to ignore the S2 bitbangio issue for now. The LC709203F does clock stretching for several ms at a time, which seems to be an issue for the S3. I cannot reproduce the problem using https://github.com/adafruit/Adafruit_LC709203F/tree/master/examples/LC709203F_demo and removing the delay in loop(). I see clock stretches in that case, but they are handled properly. So there's something different about CircuitPython, perhaps again the multiple tasks we are running.

[dhalbert]

I exercised this problem in a different way (causes a crash) in a simple ESP-IDF program on several S3 boards, and reported it comprehensively in espressif/esp-idf#8894 (comment).