creating second UART object smashes an existing I2C object

[smhodge42]

It took me days to track down (and find a workaround) for what looks like a bug, but maybe it's a known issue or something to do with the underlying Espressif framework. The workaround is that I have to create an I2C (hardware bus) AFTER creating TWO serial (UART) objects. If I do the reverse, the I2C object is apparently smashed if and when a second serial object is created. Here is a sample REPL session (done with rshell), with comments inserted:

'''py
MicroPython v1.22.2 on 2024-02-22; Generic ESP32S3 module with ESP32S3
Type "help()" for more information.

from machine import I2C,Pin,UART

create serial object 1:

ser1 = UART(1)
ser1.init(baudrate=115200, rx=6, tx=7)

create I2C object:

i2c=I2C(0, scl=Pin(15), sda=Pin(16))

scan for devices, looks good:

i2c.scan()
[64, 79, 81, 84, 85]

the device at address 81 is an external RTC (a PCF2127). Read the RTC value:

rtc=bytearray(7)
i2c.readfrom_mem_into(81, 2, rtc)
from ubinascii import hexlify
hexlify(rtc,' ')
b'30 15 13 22 05 03 24' # looks good

write it to the first serial bus:

ser1.write(rtc)
7

create a second serial object:

ser2 = UART(2)
ser2.init(baudrate=115200, rx=4, tx=5)

write to it:

ser2.write(rtc)
7

Now try reading the RTC again:

i2c.readfrom_mem_into(81, 2, rtc)
Traceback (most recent call last):
File "", line 1, in
OSError: [Errno 116] ETIMEDOUT

Did not work, presumably the I2C object was smashed.

Create a new I2C object and read the RTC again:

del i2c
i2c=I2C(0, scl=Pin(15), sda=Pin(16))
i2c.readfrom_mem_into(81, 2, rtc)
hexlify(rtc,' ')
b'20 23 13 22 05 03 24'

Looks good. The result can be written to both serial buses:

ser1.write(rtc)
7
ser2.write(rtc)
7

This can now be repeated forever. Apparently everything is now ok, now that the (new) I2C object was created after the serial ones.

i2c.readfrom_mem_into(81, 2, rtc)
ser2.write(rtc)
7
hexlify(rtc,' ')
b'28 25 13 22 05 03 24'
ser2.write(rtc)
7
i2c.readfrom_mem_into(81, 2, rtc)
hexlify(rtc,' ')
b'40 28 13 22 05 03 24'
ser1.write(rtc)
7
i2c.readfrom_mem_into(81, 2, rtc)
hexlify(rtc,' ')
b'01 30 13 22 05 03 24'

Here are the serial object parameters:

ser1
UART(1, baudrate=115211, bits=8, parity=None, stop=1, tx=7, rx=6, rts=-1, cts=-1, txbuf=256, rxbuf=256, timeout=0, timeout_char=0)
ser2
UART(2, baudrate=115211, bits=8, parity=None, stop=1, tx=5, rx=4, rts=-1, cts=-1, txbuf=256, rxbuf=256, timeout=0, timeout_char=0)

'''

Creating only the first serial bus was ok, but creating the second one smashed the I2C bus.

I then reversed the order of the object creation. Both serial objects first, then the I2C one. That worked fine from the get go. I have not shown that (successful) REPL session here.

The target is an Espressif ESP32-S3-DevKitC-01. The firmware is the latest, upgraded today.

Is this a bug? Or is there something about creating these objects that I don't know?

[peterhinch]

It certainly looks like a bug, perhaps in the ESP-IDF? It might be instructive to repeat the failing test but with a SoftI2C.

[smhodge42]

I tried SoftI2C. The results are the same, except error number 19 (ENODEV) instead of 116 (ETIMEDOUT).

[robert-hh]

If you create an UART like that:

ser2 = UART(2)
ser2.init(baudrate=115200, rx=4, tx=5)

it will first be set up using the default pins, and then the pins are re-configured with ser.init(). To avoid that, just use

ser2 = UART(2, baudrate=115200, rx=4, tx=5)

[peterhinch]

Well spotted!

[smhodge42]

Yes, that did work. Thank you.

It would be nice if the UART documentation could have a caveat added about using <init()> separately. IIRC, that always seemed to work ok with the pyboard. It took me many frustrating hours to track down that the I2C bus was smashed by something totally unrelated to I2C.

[robert-hh]

With PyBoard you usually do set the Pin assignment for UART and I2C. About ESP32's UART documentation, see https://docs.micropython.org/en/latest/esp32/quickref.html#uart-serial-bus and the sentence: To avoid conflicts simply provide tx and rx pins when constructing.
But I agree that this is a little bit concise and does not refer to conflicts with other device settings.