Closed aaronjamt closed 8 months ago
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)
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)
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.
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
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?
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.
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 frequentlyprintf
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):
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 thetinyusb
project