uart.write() ?randomly? blocks in SAMD51

[cajomferro]

I have an ATSAMD51 microcontroller integrated in a project-specific board which has also a xbee3 RF module. I've built the firmware myself based on the SPARKFUN_SAMD51_THING_PLUS port. The microcontroller is currently running Micropython v1.19.1-712-gb120d3b2f including this patch which affected the uart.read().

I can access the Microcontroller REPL via UART (over USB port on macos) and I've managed to send/receive commands to the xbee3 via a secondary UART.

However, there seems to be a problem with the uart.write() function. Randomly (seems to me) this function blocks the entire microcontroller (cannot use the REPL anymore), and only a button reset can fix it. Moreover, after the reset I have to wait some seconds ( ~10) before I can access the REPL again.

This is a simple demo I've made to try to characterize the problem:

from utime import sleep, sleep_ms
from machine import UART, Pin

uart = UART(5, rx=Pin('XBEE_RX'), tx=Pin('XBEE_TX'), baudrate=115200)

def start(time_ms=500):
    x = 1
    while True:
        print(f"#{x}")
        uart.write('foo')
        sleep_ms(50) # wait a bit for xbee to process info, otherwise nothing will be read
        data = uart.read()
        if data:
            data = data.decode("utf-8").strip()
        print(data)
        x += 1
        sleep_ms(time_ms)

I've run this demo using different sleeping durations (50ms, 100ms, and 1000ms). The numbers on the right represent the iteration when the uart.write() blocks. So, for example, using time_ms=50 on the second run, it got 249 iterations before blocking and using time_ms=100 on the fifth run, it got only 2 iterations before blocking. So it seems to me it is a random behavior right?

time_ms	iteration where it blocks.
50ms	69, 249, 143, 65, 207, 360, 4
100ms	57, 29, 110, 31, 2, 189, 6
1000ms	154, 70, 75, 30, 25, 99, 138

Can anyone replicate this situation?

Thank you in advance and congratulations on the Micropython project. It is awesome!!

[robert-hh]

Thank you for the report. I have set up the test with a ItsyBitsy M4, but at first I just loop back tx to RX. Not stops within > 1000 iterations for both 50ms and 100ms. I have set up a simple echo test as well (see below) using an rp2 as counterpart with the same results. Only the rp2 seems to pile up incoming messages, if the delay is shorter than 70ms. You may as well try the loopback test to sort out the XBEE.
The 10sec delay after reset is strange. I have never seen this, and I push reset pretty often.

from machine import UART, Pin
import time

uart=UART(0, rx=Pin(1), tx=Pin(0))

n=0
while True:
    data = uart.read(3)
    if data:
        print(n, data)
        n += 1
        time.sleep_ms(10)
        uart.write("bar")

[robert-hh]

My tests were done with an end-around on each machine.. talking to itself.

Therefore it works without the samd_sp2 patches.

[robert-hh]

@ricksorensen So I found the reason. The UART object is created with a finalizer. As such, del is called for it when the object went out of scope and garbage collection runs. Then, uart.deinit() is called, which kind of stopped the code halfways. That is to be fixed. During that analysis, I could as well simplify the code a little bit. The only thing I have to determine is, whether the del code must free the object it's called for.

[robert-hh]

@ricksorensen @cajomferro I have update the samd_sp2 branch. It worked well in a few test series of >10000 iterations. The new code is a little bit smaller and simpler.

[ricksorensen]

Thanks so much for finding these solutions! I ran a test program with stressing the reassignment of the UART - 20 reassignments of the same UART config to a function variable on both the SAMD21 XIAO and SAMD51 WIO Terminal - with no failures. (In both cases it was UART(4)) ... Looking at memory with gc.mem_free() after a gc.collect() there was no change in the available GC memory on either MCU.

Thanks again.

[cajomferro]

@robert-hh thank you for the nice support! I'll let you know my test once I got back to work on it (probably next week).

[robert-hh]

Fixed by #10021 .