RP2040: Issuing `run` disconnects the target

[xobs]

Under some circumstances, it seems as though issuing a run command disconnects the target. For example, when attempting to load tinyusb_dev_cdc_dual_ports.elf:

Reading symbols from E:\Code\Farpatch\tinyusb_dev_cdc_dual_ports.elf...done.
(gdb) tar ext \\.\COM54
Remote debugging using \\.\COM54
(gdb) mon ver
Black Magic Probev1.8.0-903-g22139ea9, Hardware Version 6
Copyright (C) 2022 Black Magic Debug Project
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

(gdb) mon s
Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      Raspberry RP2040 M0+
 2      Raspberry RP2040 M0+
 3      Raspberry RP2040 Rescue (Attach to reset!)
(gdb) att 1
Attaching to program: E:\Code\Farpatch\tinyusb_dev_cdc_dual_ports.elf, Remote target
0x100011a0 in alarm_pool_get_default () at /opt/Pico/pico-sdk/src/common/pico_time/time.c:93
93      /opt/Pico/pico-sdk/src/common/pico_time/time.c: No such file or directory.
(gdb) load
Loading section .boot2, size 0x100 lma 0x10000000
Loading section .text, size 0x6f20 lma 0x10000100
Loading section .rodata, size 0x1638 lma 0x10007020
Loading section .binary_info, size 0x28 lma 0x10008658
Loading section .data, size 0x330 lma 0x10008680
Loading section .uninitialized_ram.magic_location, size 0xc lma 0x100089b0
Start address 0x100001e8, load size 35260
Transfer rate: 51 KB/sec, 881 bytes/write.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: E:\Code\Farpatch\tinyusb_dev_cdc_dual_ports.elf
You are now detached from the previous target.

Program terminated with signal SIGLOST, Resource lost.
The program no longer exists.
[New Thread 1]
Remote failure reply: EFF
Remote failure reply: EFF
(gdb)

When the board gets into this state, it behaves very oddly:

Remote failure reply: EFF
Remote failure reply: EFF
(gdb) mon erase_mass
Target does not support this command.
(gdb) att 1
A program is being debugged already.  Kill it? (y or n) y
Attaching to program: E:\Code\Farpatch\tinyusb_dev_cdc_dual_ports.elf, Remote target
Attaching to Remote target failed
(gdb) mon s
Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      Raspberry RP2040 M0+
 2      Raspberry RP2040 M0+
 3      Raspberry RP2040 Rescue (Attach to reset!)
(gdb) att 1
Attaching to program: E:\Code\Farpatch\tinyusb_dev_cdc_dual_ports.elf, Remote target
0x000020f0 in ?? ()
(gdb) mon erase_mass
Erasing device Flash: .................................................done
Failed
(gdb)

This happens with tinyusb_dev_cdc_dual_ports.elf, and does not happen with the simple blink.elf. However, curiously enough I've found instances where blink.elf doesn't actually blink. In this case might it be that the second CPU isn't halted?

[jamesturton]

I'm not able to reproduce this error so I would be interested to know which HW you are using for your rp2040 and which version of the pico SDK you are building with. Also, how are you powering your rp2040 board? As a USB controller can choose to turn of the power to connected peripherals whenever they want, it could be the USB controller who resets the processor causing it to loose contact with the BMP.

However, curiously enough I've found instances where blink.elf doesn't actually blink. In this case might it be that the second CPU isn't halted?

Unless the program is made to use the second processor it will go to sleep immediately on start-up (WFE with SCR.SLEEPDEEP enabled) and remains asleep. As the blink example does not use the second processor then it should not be running when you said that your board doesn't blink, the problem must be somewhere else.

[xobs]

I'm using the Raspberry Pi Pico. I'm not sure if there's any further revision data I can give.

The RP2040 is powered from the same USB hub as the BMP, which I believe is cheap enough to not include power switches on the ports. The BMP itself doesn't get disconnected. Additionally, I can reproduce the issue by plugging the Pico into a USB power bank.

I'm using the most recent version of pico-sdk which appears to be 1.4.0: raspberrypi/pico-sdk@2e6142b

[dragonmux]

Hi xobs, is this still an issue or is it fixed as of latest main? We'd like to know if there's still work to do here so we can start figuring out what and developing a fix

[xobs]

@dragonmux It does look fixed now! Thanks for the followup:

(gdb) tar ext 10.0.237.133:2022
Remote debugging using 10.0.237.133:2022
(gdb) mon s
Target voltage: 6926mV (TMS: 6959mV, TDO: 5789 mV)
Available Targets:
No. Att Driver
 1      Raspberry RP2040 M0+
 2      Raspberry RP2040 M0+
 3      Raspberry RP2040 Rescue (Attach to reset!)
(gdb) att 1
Attaching to program: /opt/Pico/examples/build/usb/device/dev_hid_composite/dev_hid_composite.elf, Remote target
0x000020f0 in ?? ()
(gdb) load
Loading section .boot2, size 0x100 lma 0x10000000
Loading section .text, size 0x6810 lma 0x10000100
Loading section .rodata, size 0x14d8 lma 0x10006910
Loading section .binary_info, size 0x28 lma 0x10007de8
Loading section .data, size 0x38c lma 0x10007e10
Start address 0x100001e8, load size 33180
Transfer rate: 12 KB/sec, 896 bytes/write.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /opt/Pico/examples/build/usb/device/dev_hid_composite/dev_hid_composite.elf
^C
Program received signal SIGINT, Interrupt.
board_millis () at /opt/Pico/pico-sdk/lib/tinyusb/hw/bsp/board.h:91
91          return to_ms_since_boot(get_absolute_time());
(gdb) bt
#0  board_millis () at /opt/Pico/pico-sdk/lib/tinyusb/hw/bsp/board.h:91
#1  led_blinking_task () at /opt/Pico/examples/usb/device/dev_hid_composite/main.c:297
#2  0x10000606 in main () at /opt/Pico/examples/usb/device/dev_hid_composite/main.c:64
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x100005a4 in led_blinking_task () at /opt/Pico/examples/usb/device/dev_hid_composite/main.c:297
297       if ( board_millis() - start_ms < blink_interval_ms) return; // not enough time
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /opt/Pico/examples/build/usb/device/dev_hid_composite/dev_hid_composite.elf