ESP32-S3 I2C timeout with seesaw

[icebreaker87]

CircuitPython version

Adafruit CircuitPython 9.1.1 on 2024-07-22; Adafruit Feather ESP32S3 No PSRAM with ESP32S3

Code/REPL

import time
import busio
import board
from micropython import const
from adafruit_seesaw.seesaw import Seesaw

BUTTON_X = const(6)
BUTTON_Y = const(2)
BUTTON_A = const(5)
BUTTON_B = const(1)
BUTTON_SELECT = const(0)
BUTTON_START = const(16)
button_mask = const(
    (1 << BUTTON_X)
    | (1 << BUTTON_Y)
    | (1 << BUTTON_A)
    | (1 << BUTTON_B)
    | (1 << BUTTON_SELECT)
    | (1 << BUTTON_START)
)

i2c_bus = board.STEMMA_I2C()
seesaw = Seesaw(i2c_bus, addr=0x50)
seesaw.pin_mode_bulk(button_mask, seesaw.INPUT_PULLUP)

Behavior

Traceback (most recent call last):
File "", line 33, in
File "adafruit_seesaw/seesaw.py", line 342, in pin_mode_bulk
File "adafruit_seesaw/seesaw.py", line 329, in _pin_mode_bulk_x
File "adafruit_seesaw/seesaw.py", line 520, in write
OSError: [Errno 116] ETIMEDOUT

Description

This is the example code from adafruits gamepad qt guide. Get this everytime I try to run the code. After multiple tries, there is an error :
Traceback (most recent call last):
File "", line 27, in
RuntimeError: No pull up found on SDA or SCL; check your wiring

Bus this goes away if you unplug the board and power back on. On RP2040 based boards, it works out of the box (same CP version).
If I use the same hardware but with arduino code (also from gamepad qt guide), it works always.

Additional information

No response

[icebreaker87]

If I run the I2C scan (https://learn.adafruit.com/scanning-i2c-addresses/circuitpython), it does see the device at 0x50, but can't "speak" to it

[deshipu]

It's hard to be sure without looking at the signals on the bus, but it looks like the seesaw device is crashing leaving the SCL line pulled low, that's why you get a timeout when the CircuitPython side waits on clock stretching, and it fails the test for pull-up resistors (because the line is kept low by the other side). Might be some combination of a bug in the seesaw device code, and different timings on different ports?

[dhalbert]

Try setting the I2C busio frequency to 400000:
Replace:

i2c_bus = board.STEMMA_I2C()

with

import busio
# ...
i2c_bus = busio.I2C(board.SCL, board.SDA, frequency=400000)

There's a thread here: https://forums.adafruit.com/viewtopic.php?p=978381 that suggests that at least in some circumstances, that helps. That thread was about an RPi (not Pico).

As for the motor controller you mentioned in your forum thread, I have written to Kitronik, because I don't know whether there are pull-up resistors on their board. They don't appear to publish a schematic.

[icebreaker87]

I have tried with your code, sadly shows exactly the same behavoir.

@deshipu but with arduino code it seems to work fine. This is why i thought, it would be more on the circuit python side, as the hardware is the same, just running a different code on. Sadly I don't have the equipment for testing the bus, I only own a multimeter.

[dhalbert]

I tried a similar seesaw board, Adafruit ANO Rotary Navigation Encoder to I2C Stemma QT Adapter, and was able to reproduce the problem, with both frequency=100000 and frequency=400000. However, the program does not get ETIMEDOUT with:

i2c_bus = busio.I2C(board.SCL, board.SDA, frequency=50000)

Try that and see if it lets you proceed.

[bill88t]

This happens to me on the lilygo_twatch_s3 when files are being written with usb and the board is in it's low power state @ 40Mhz.
It's not related to a specific i2c library.

[icebreaker87]

i2c_bus = busio.I2C(board.SCL, board.SDA, frequency=50000)

With this speed, it works perfect.

[icebreaker87]

@bill88t if I run this code:

import microcontroller
microcontroller.cpu.frequency

the output is:

240000000

which to me sounds like full speed

[icebreaker87]

@dhalbert If I test again with the motor driver, it's working now too. The only thing I have changed, is a bigger power supply (LiPo wit DC-DC Stepdown). Nothing changed in the code.

[dhalbert]

@icebreaker87 Glad to hear on both counts. I will check about the 50000 speed requirement internally. And it sounds like it was power sag on the motor driver.

[tannewt]

This could be an artifact of our tick speed change from 100 to 1000. That shortens timeouts like:

circuitpython/ports/espressif/common-hal/busio/I2C.c

Line 176 in 830294e

: i2c_master_write_to_device(self->i2c_num, (uint8_t)addr, data, len, 100 /* wait in ticks */)

We should change the timeouts to be tick speed agnostic.

EDIT: @tannewt did this in #9607.