search

raspberrypi / pico-feedback

25 stars 2 forks source link

Load and debug program in RAM without flash using gdb / openocd (-DPICO_NO_FLASH=1) #153

Open perexg opened 3 years ago

perexg commented 3 years ago

The program loading and debugging procedure for -DPICO_NO_FLASH=1 compilation option is not documented (gdb / openocd). I went through some trial and error steps to make it work. It would be probably nice to document this. My sequence:

elf="program.elf"
gdb -ex "target extended-remote localhost:3333" \
    -ex "monitor reset init" \
    -ex "load ${elf}" \
    -ex "continue" \
    "${elf}"

If everything is ok (program is in RAM - starts at 0x20000000):

Remote debugging using localhost:3333
Loading section .text, size 0x838c lma 0x20000000
Loading section .rodata, size 0x19c4 lma 0x20008390
Loading section .binary_info, size 0x1c lma 0x20009d54
Loading section .data, size 0x108 lma 0x20009d70
Start address 0x20000000, load size 40564
Transfer rate: 13 KB/sec, 6760 bytes/write.
Continuing.
kilograham commented 3 years ago

note that this works for all program types

perexg commented 3 years ago

Thank you for the clarification. The getting started guide use load + reset init sequences which works only for the flash programs. The RAM loading / booting requires the reset halt + load otherwise you can encounter weird behavior like the USB device enumeration failures (no BUS RESET interrupts) etc. when you jump to the updated RAM program without reset. The reset init boots always to flash, of course.

kilograham commented 3 years ago

oh, thanks... I didn't realize that was there

@lurch can you fix to move the monitor reset init before the load in section 6.3

perexg you see issues with monitor reset init then load... that's what I used and have never seen an issue...

perexg commented 3 years ago

It seems that monitor reset init and monitor reset halt do both the right job. The only difference is initial PC address (0xf0 or 0x2700). The order of monitor reset and load commands matters for the no-flash program. I apologize for the confusion.

aallan commented 3 years ago

@lurch can you fix to move the monitor reset init before the load in section 6.3

@lurch Did this get done, or still in backlog?

lurch commented 3 years ago

Still in backlog.

martin2250 commented 1 year ago

For anyone struggling with VSCode and Cortex-Debug: I was able to debug my "no_flash" binary by replacing the postRestartCommands in the launch.json from the examples with:

"overrideLaunchCommands": [
    "monitor reset init",
    "load ${command:cmake.launchTargetPath}"
],

I remember this working without this workaround, maybe something changed in the recent releases of the SDK.

lurch commented 1 month ago

I no longer work on the documentation, so transferring this issue to @nathan-contino instead :slightly_smiling_face: