Open ali1234 opened 2 months ago
While attempting to debug this I accidentally left the Pico halted in the debugger which triggers the "XHCI died" linux bug, disabling all USB ports on the host computer and forcing a reboot. After the reboot I could no longer reproduce the serial locking up. I didn't even reflash the Pico after rebooting so it is definitely the same firmware. So this seems like a Linux serial port bug.
I tried your example and couldn't reproduce it either.
This hangs for me randomly after a day or so:
#include <pico/stdlib.h>
#include <pico/stdio_usb.h>
#if !defined(PICO_DEFAULT_LED_PIN)
#error blink example requires a board with a regular LED
#endif
#define LED_PIN PICO_DEFAULT_LED_PIN
int main()
{
stdio_usb_init();
gpio_init(LED_PIN);
gpio_set_dir(LED_PIN, GPIO_OUT);
gpio_put(LED_PIN, 1);
for (int i = 0; i < 20; i++) {
if (stdio_usb_connected())
break;
gpio_put(LED_PIN, i & 1);
sleep_ms(100);
}
gpio_put(LED_PIN, 0);
while (true) {
int c = getchar_timeout_us(100);
if ('W' == c)
gpio_put(LED_PIN, 1);
else if ('w' == c)
gpio_put(LED_PIN, 0);
sleep_ms(50);
}
}
try with the develop
branch; there was a timer bug fixed there which might be the cause
To reproduce, build and flash this code to a Pico (not Pico W because the LED won't blink):
Now on PC run this, redirecting to whatever serial port the Pico is on:
Expected result: the LED blinks whenever a character is received, for as long as you leave
cat
running. (Note it will appear to be always on and dim, because this happens very fast.)Actual result: the LED stops blinking / turns off after about 1 to 10 seconds.
pv
shows that data is no longer moving - the port is stalled because it thinks the buffer is full. But the pico is deadlocked insidegetchar()
presumably because it thinks the buffer is empty. If you runcat
again, it will blink again, for a while, and then lock up again.This seems easier to reproduce in real code on a RP2350, but example code fails on RP2040 as well.