search

majbthrd / pico-debug

virtual debug pod for RP2040 "Raspberry Pi Pico" with no added hardware
386 stars 50 forks source link

breakpoint has to be set twice? #25

Closed sv8194 closed 2 years ago

sv8194 commented 2 years ago

Hi, I am not sure if it's an issue with pico-debug or my settings. When I tried to debug LED blinking code in the SDK examples, I have to load the ELF 2x. Here is the log:

yibing@copper:~/project/rpi_pico/test_led/build$ gdb-multiarch test_led.elf GNU gdb (Ubuntu 8.1.1-0ubuntu1) 8.1.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from test_led.elf...done. (gdb) target remote localhost:3333 Remote debugging using localhost:3333 time_reached (t=...) at /home/yibing/project/rpi_pico/sdk/src/rp2_common/hardware_timer/include/hardware/timer.h:116 116 uint32_t hi_target = (uint32_t)(target >> 32u); (gdb) load Loading section .text, size 0x3fd4 lma 0x20000000 Loading section .rodata, size 0xeb8 lma 0x20003fd8 Loading section .binary_info, size 0x14 lma 0x20004e90 Loading section .data, size 0xb8 lma 0x20004eb0 Start address 0x20000000, load size 20312 Transfer rate: 23 KB/sec, 4062 bytes/write. (gdb) monitor reset init [rp2040.cpu] halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00 (gdb) b main Breakpoint 1 at 0x200002b0: file /home/yibing/project/rpi_pico/test_led/test_led.c, line 9. (gdb) cont Continuing. ^C Program received signal SIGINT, Interrupt. 0x100011c8 in ?? () (gdb) load Loading section .text, size 0x3fd4 lma 0x20000000 Loading section .rodata, size 0xeb8 lma 0x20003fd8 Loading section .binary_info, size 0x14 lma 0x20004e90 Loading section .data, size 0xb8 lma 0x20004eb0 Start address 0x20000000, load size 20312 Transfer rate: 23 KB/sec, 4062 bytes/write. (gdb) b main Note: breakpoint 1 also set at pc 0x200002b0. Breakpoint 2 at 0x200002b0: file /home/yibing/project/rpi_pico/test_led/test_led.c, line 9. (gdb) cont Continuing.

Breakpoint 1, main () at /home/yibing/project/rpi_pico/test_led/test_led.c:9 9 int main() { (gdb)

You see that the first "cont/continue" command, gdb doesn't stop at main(). It does after I loaded it the 2nd time and set the BP again.

BTW, my C code is set to run from RAM with "pico_set_binary_type(test_led no_flash)" in CMakeLists.txt.

Thanks Mark

sv8194 commented 2 years ago

It seems to me it's only a problem if I load/run the code from RAM. Flash works fine. I guess I missed some steps for gdb to run it properly from RAM? I commented out "pico_set_binary_type(test_led no_flash)" from CMakeLists.txt and the problem was no longer there.

I tried "-DPICO_NO_FLASH=1" to cmake, it didn't fix it.

majbthrd commented 2 years ago

It has absolutely nothing to do with pico-debug.

Think about it. The only Raspberry-approved way to run a RAM target is to load a specially crafted .uf2 that the Mask ROM is designed to branch to. From the very start, you are asking the RP2040 target to do something it is not designed to do.

OpenOCD and gdb have a generic ARM debugger implementation that assumes that all execution starts from a reset, which in the RP2040 case means executing the Mask ROM... which has no interest or knowledge of your custom RAM code.