RPi Pico Error `WARN: starting new transfer on already active ep 0 out`

[aaronjamt]

Describe the bug Whenever I run a Pi Pico program (using the C/C++ SDK) that includes stdio_init_all();, it gives this error and frequently printf results in corrupted data being printed to the terminal.

To Reproduce See the file I attached below. If you extract the archive and run snowflake/snowflake.uf2 in Wokwi, it will show the error in the serial terminal. The source is included as well as the build files (assuming the archive is extracted to /tmp/snowflake).

Expected behavior I expect not to see this warning/error and, since this is a simulation not real hardware, there wouldn't be any data corruption issues (other than as a direct result of my code being buggy).

Environment (please complete the following information):

• OS: Ubuntu 22.10
• No browser, using VSCode
• VSCode is Version 1.75.1 with Electron 19.1.9 and Chromium 102.0.5005.194. The Wokwi extension is version 1.3.0 (the latest at the time of writing). The RPi Pico SDK is version 1.4.0. (Update: I just updated my SDK to 1.5.0 and it has the same issue)

Additional context Here's a small program that reproduces this error, including the build files from my machine.

Update 2: Looks like this error is printed at line 218 of rp2040_usb.c in the tinyusb project

[aaronjamt]

When I run stdio_uart_init(); without stdio_usb_init(); it doesn't have the WARN: starting new transfer on already active ep 0 out error but it still has data corruption issues. When I just use stdio_usb_init(); the serial console never appears (so the simulated serial terminal must be UART, then, right?) However, even with that error not showing up, there's still data corruption in the serial monitor.

Edit: example of the corruption: what should say "Starting in 500 millis..." actually says "Starting in 5°0 millis..." (notice the degrees symbol in place of the middle zero in the five hundred)

[urish]

Thanks for reporting!

For seeing the stdio output, simply add the following connections to your diagram.json:

  "connections": [
    [ "pico:GP0", "$serialMonitor:RX", "", [] ], 
    [ "pico:GP1", "$serialMonitor:TX", "", [] ] 
  ],

(you can always copy them from https://wokwi.com/projects/new/pi-pico-sdk which uses this setup)

[aaronjamt]

Thanks for reporting!

For seeing the stdio output, simply add the following connections to your diagram.json:

  "connections": [
    [ "pico:GP0", "$serialMonitor:RX", "", [] ], 
    [ "pico:GP1", "$serialMonitor:TX", "", [] ] 
  ],

(you can always copy them from https://wokwi.com/projects/new/pi-pico-sdk which uses this setup)

I already have those lines and printf "works". It just has data corruption issues and that warning/error whenever it enables USB serial I/O.

[urish]

Got it! Unfortunately, I don't have the bandwidth to look into this at the moment.

In case someone else wants to look into this, it can be reproduced with rp2040js by downloading the snowflake.zip attachment from the first comment in this issue, adding the following code at the end of demo/micropython-run.ts:

mcu.uart[0].onByte = (value) => {
  process.stdout.write(new Uint8Array([value]));
};

and then running the simulator it as follows:

npm run start:micropython -- --gdb --image snowflake/build/snowflake.uf2

[aaronjamt]

Got it! Unfortunately, I don't have the bandwidth to look into this at the moment.

In case someone else wants to look into this, it can be reproduced with rp2040js by downloading the snowflake.zip attachment from the first comment in this issue, adding the following code at the end of demo/micropython-run.ts:

mcu.uart[0].onByte = (value) => {
  process.stdout.write(new Uint8Array([value]));
};

and then running the simulator it as follows:

npm run start:micropython -- --gdb --image snowflake/build/snowflake.uf2

No worries if you don't have time/bandwidth right now, it's more of an annoying warning than anything actually problematic. As it turns out, the corrupt serial output was my bad because I was using GPIOs 0 and 1 without realizing that the simulated UART connection was also using those pins (so any time my code changed the GPIO state it messed with the UART data).

Just one quick question: your commands to reproduce say npm run start:micropython but I'm using the RPi Pico C/C++ SDK (not MicroPython). Could that have something to do with it?

[urish]

Thanks for the update!

Regarding your question, not at all - the micropython demo app is called that way because we used it initially to test micropython, but it can run any Pi Pico UF2 binary. It does have some defaults that work well for micropython (such as using Serial over USB and not the standard UART). But you can use it to run any binary built with he RPi Pico C/C++ SDK.