support pure RAM programs

[japaric]

Context: most of the time spent in running a defmt-test test suite goes into loading the test images. Program loading can take seconds whereas tests are usually completed in less than one second. If the test suite comprises of several test files the problem is further aggravated. This leads to very slow edit-compile-test cycles.

Goal: speed up program loading by at least 2x (because a erase step is not required when writing to RAM)

Implementing this requires several changes

• probe-run won't load programs into RAM at all because it uses a probe-rs API that only writes to Flash memory.

• probe-run won't properly start pure RAM programs because it uses a 'software reset' to start the program and by default this makes the CPU use the vector table located in Flash. This can be fixed by making probe-run do a reset halt and then having it patch the target's VTOR, SP, PC registers to the values in the RAM vector table.

(NOTE: we probably have the logic for these 2 steps in an old version of probe-run)

• cortex-m-rt doesn't have good support for pure RAM programs. One can make this work by lying about the location of FLASH in a linker script but this cumbersome and error prone -- HALs that provide their own memory.x file further complicate things. The most convenient way to solve this would be making probe-run itself modify the ELF file on the fly to remap linker sections from Flash to RAM when some flag is specified (e.g. --ram) -- this may not be straightforward to implement because all the absolute addresses would need to be fixed up (some of these may be encoded in ARM instructions; others may be in debug info).

[sszilvasi]

I recently experimented with no-FLASH projects and ended up creating a proof-of-concept RAM-only project template by comparing two memory layouts in pico-sdk:

1. https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/pico_standard_link/memmap_default.ld
2. https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/pico_standard_link/memmap_no_flash.ld

As the target RP Pico used for development does actually have a FLASH, I "disabled" it by flashing picoblank to the boot loader region. The debugger RP Pico had the DapperMime firmware on it.

The RAM-only project currently works with elf2uf2-rs and teleprobe, but fails with probe-run:

$ cargo run
    Finished dev [optimized + debuginfo] target(s) in 0.05s
     Running `probe-run --chip RP2040 target/thumbv6m-none-eabi/debug/rp2040-project-template`
(HOST) INFO  success!
Error: A core architecture specific error occured

Caused by:
    Unsupported address 0x2003c550 for HW breakpoint. Breakpoint must be at address < 0x2000_0000.

Does probe-run error out due to the problem described in this issue?

[japaric]

Does probe-run error out due to the problem described in this issue?

doesn't look like but the analysis in the issue description is one year old and may no longer be accurate. from looking at the output of cargo run you posted it seems that loading the program to RAM worked but probe-run failed afterwards when it tried to set some breakpoints. the breakpoints are used to catch hardware faults (I don't remember if they have other uses)

Unsupported address 0x2003c550 for HW breakpoint. Breakpoint must be at address < 0x2000_0000.

this is a limitation of the v6-M variant (or I think anything that ships with FPB v1, iirc). you cannot put a hardware breakpoint in RAM (usually located at 0x2000_0000) but you can put any number of software breakpoints in RAM (software breakpoints only work on half-word writeable memory). from a quick look at the probe-rs API docs it doesn't seem like it supports software breakpoints through a high-level API but I guess it should be possible to implement software breakpoints on top of the existing API

[sszilvasi]

Would implementing software breakpoints on top of the existing API need to happen in the probe-rs repo then?

[japaric]

Would implementing software breakpoints on top of the existing API need to happen in the probe-rs repo then?

not strictly necessary but that would be the best place for such functionality to reside in.