BMP hangs after load on raspberry pico

[ptillemans]

When running the master branch when I load the program after attach to the first target (mon s shows 3 targets so basic comms works) it hangs on:

Reading symbols from blink.elf...
(gdb) tar ext /dev/ttyACM0
Remote debugging using /dev/ttyACM0
(gdb) mon s
Available Targets:
No. Att Driver
 1      Raspberry RP2040 M0+
 2      Raspberry RP2040 M0+
 3      Raspberry RP2040 Rescue(Attach to reset!) 
(gdb) attach 1
Attaching to program: /home/pti/sandbox/pico-examples/build/blink/blink.elf, Remote target
0x10000c0a in sleep_until ()
(gdb) load
Loading section .boot2, size 0x100 lma 0x10000000

then it hangs....

When I revert to the version with tag v1.8.2 it succeeds just fine:

Reading symbols from blink.elf...
(gdb) tar ext /dev/ttyACM0
Remote debugging using /dev/ttyACM0
(gdb) mon s
Available Targets:
No. Att Driver
 1      Raspberry RP2040 M0+
 2      Raspberry RP2040 M0+
 3      Raspberry RP2040 Rescue(Attach to reset!) 
(gdb) attach 1
Attaching to program: /home/pti/sandbox/pico-examples/build/blink/blink.elf, Remote target
0x10000c0a in sleep_until ()
(gdb) load
Loading section .boot2, size 0x100 lma 0x10000000
Loading section .text, size 0x1d80 lma 0x10000100
Loading section .rodata, size 0xf8 lma 0x10001e80
Loading section .binary_info, size 0x20 lma 0x10001f78
Loading section .data, size 0x59c lma 0x10001f98
Start address 0x100001e8, load size 9524
Transfer rate: 27 KB/sec, 732 bytes/write.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/pti/sandbox/pico-examples/build/blink/blink.elf 

This is on a bluepill compiled with

make PROBE_HOST=swlink

(I ordered a real BMP to compare but in the meantime I can proceed with using the v1.8.2 version)

[dragonmux]

Couple of questions to help us determine if this is a regression, etc:

1. for Bluepill, you should be building with make PROBE_HOST=stlink BLUEPILL=1 as this then gives the correct pinouts and such. Could you confirm that firmware built this way still hangs
2. Removing a couple of targets you're not currently using from src/Makefile (delete a few .c lines for processors you're not currently debugging such as the LPC suite), could you please make PROBE_HOST=stlink BLUEPILL=1 ENABLE_DEBUG=1 and re-run your test adding mon debug en before your SWD scan, and monitoring the other serial port (/dev/ttyACM1 in your setup, probably), as this will give us a debug log of what's going on.

If you could make the debug log available here by Gist or similar, or attaching a file with the output, that will allow us to dive in and see what could be causing this. We have RP2040's locally to test against and try to reproduce this.

Edit: Also, a small point for clarification, when you say "master branch", do you mean main? Asking just so we're absolutely clear on what's being referred to by that

[ptillemans]

I have been trying to remove targets but I keep getting linker errors. So I cannot yet enable debugging.

I am using this script to build:

#!/bin/sh
make -j9 clean
make PROBE_HOST=swlink BLUEPILL=1 -j9
dfu-util -v -R -d 0483:df11 -s 0x08002000 -D src/blackmagic.bin

and I have the following in .gdbinit for the pico-examples blinky example

target ext /dev/ttyACM0
mon s
attach 1
load

my tests so far:

• v1.8.2 works
• v1.9.0-rc0 works
• v1.9.0-rc1 fails on mon s
• main (302c8b5) works (???)

I am sorry, it seems the issue has magically disappeared. Something in my setup, PC (or most likely between chair and computer) makes the results flaky. (I did reproduce it earlier today, then scripted everything to remove operator variance and now it does not anymore)

[ptillemans]

Yesterday I enabled RTT with ENABLE_RTT=1

In that case I get the observed behavior. I probably got confused with inconsistent settings for ENABLE_RTT.

if I change the build.sh to

#!/bin/sh
make -j9 clean
make PROBE_HOST=swlink BLUEPILL=1 ENABLE_RTT=1 -j9
dfu-util -v -R -d 0483:df11 -s 0x08002000 -D src/blackmagic.bin
git checkout .

results in

• v1.8.2 works (no support yet for this flag?)
• v1.9.0-rc0 hangs on loading section .boot2
• v1.9.0-rc1 fails on mon s
• main ( 302c8b5 ) hangs on loading section .boot2

which is what I originally observed.

[dragonmux]

v1.9.0-rc1 failing on mon s is a known issue that we've fixed in #1360 so that's expected. v1.8.2 predates RTT support as you observed.

Thank you for providing the extra information, we might now be able to figure out why RTT has broken RP2040 support when enabled. We'd been wondering why we couldn't reproduce it (with RTT off as we don't typically enable it), so that limits it down to an interaction between the two.

[dragonmux]

So, we've been trying to reproduce this with the information provided and.. funny problem - it works flawlessly on native from what we can tell. Transfer speed seems a little down over no-RTT builds, but all works exactly how we'd expect both with RTT off and RTT on but built into the firmware in both cases.

For now we'll bump this issue to v1.10 as reproducing this might take a lot more work.

[ptillemans]

I am waiting for the arrival of the BMP official hardware so I have something to compare against as I have gotten intrigued by this issue. If I could get the bluepill to work I would have a nice solution to just solder the programmer in place in my project rather than fiddle with custom cables et al. As they are cheap as chips I can just leave them in the project box while it is active which saves me ton of setup time in my workspace. But it will be nice to have a benchmark official hardware part to compare to, because it is hard to get confidence in these cheap parts, my soldering skills, my PC setup, cabling, software versions... There are so many variables. In any case awesome work it really works well in my experiments so far.

…

On Mon, Jan 23, 2023 at 6:46 AM Rachel Mant ***@***.***> wrote: So, we've been trying to reproduce this with the information provided and.. funny problem - it works flawlessly on native from what we can tell. Transfer speed seems a little down over no-RTT builds, but all works exactly how we'd expect both with RTT off and RTT on but built into the firmware in both cases. For now we'll bump this issue to v1.10 as reproducing this might take a lot more work. — Reply to this email directly, view it on GitHub <#1364 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAK2MOF2ADSEBA6HUCNNGLWTYLK7ANCNFSM6AAAAAAUCVTSM4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[gresolio]

I can also confirm, flashing pi pico hangs after load command.
Sometimes I get "Error erasing flash with vFlashErase packet", but most of the time it just hangs.

• latest main (at the moment 7b05ecc) = hangs
• latest v1.9 (at the moment 1fd6cb1) = hangs
• v1.8.0-266-g37efd257 (GDB11+ fixes 37efd25) = OK

Compile options, MINGW64 on Windows:

mingw32-make PROBE_HOST=stlink ENABLE_RTT=1

Upload script:

target extended-remote $serial_interface
file $target_elf_path
mon swdp_scan
att 1
load
kill
q

p.s. I ordered BMP23 Native Hardware, I'll write the results later.

[dragonmux]

Thank you for partially bisecting when this was introduced! We haven't yet been able to repro this but we can look at the history on rp.c and see what changes impacting the Flash routines were made between 37efd25 and v1.9 and see if there's anything obvious with that information.

[gresolio]

Thanks for the great open source project :)
37efd25 is the most stable commit in my use case with RP2040 and RTT feature.