Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
perexg opened this issue May 1, 2021 · 8 comments
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@perexg
Copy link

perexg commented May 1, 2021

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
Copy link

note that this works for all program types

@perexg
Copy link
Author

perexg commented May 2, 2021

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
Copy link

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...

@lurch lurch added the documentation Improvements or additions to documentation label May 2, 2021
@perexg
Copy link
Author

perexg commented May 5, 2021

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
Copy link
Contributor

aallan commented May 25, 2021

@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
Copy link
Contributor

lurch commented May 25, 2021

Still in backlog.

@martin2250
Copy link

martin2250 commented Apr 6, 2023

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
Copy link
Contributor

lurch commented Sep 18, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

6 participants