probe-run times out but cargo-embed does not for LPC546xx MCUs

[allexoll]

Describe the bug probe-run times out when running an example for LPC546XX, where cargo-embed suceeds.

To Reproduce

1. write example/gpio.rs

   
   #![no_main]
   #![no_std]

use cortex_m_rt::entry;

use defmtrtt as ; use lpc546xx_hal as hal; use panicprobe as ;

[entry]

fn main() -> ! { defmt::error!("message from target"); loop { cortex_m::asm::nop(); } }

2. Run it with ` cargo run --example gpio --features=mcu-LPC54608J512ET180,rt`

**Expected and observed behavior**
Expected: 

flashing program success! ERROR: message from target

Observed:

Finished dev [optimized + debuginfo] target(s) in 29.52s
 Running `probe-run --chip LPC54608J512ET180 --speed 100 --verbose target/thumbv7em-none-eabi/debug/examples/gpio`

(HOST) DEBUG vector table: VectorTable { initial_stack_pointer: 20031bc8, hard_fault: 149b } └─ probe_run::elf @ /Users/allexoll/.cargo/registry/src/github.com-1ecc6299db9ec823/probe-run-0.3.1/src/elf.rs:29 (HOST) DEBUG found 1 probes └─ probe_run::probe @ /Users/allexoll/.cargo/registry/src/github.com-1ecc6299db9ec823/probe-run-0.3.1/src/probe.rs:25 (HOST) DEBUG opened probe └─ probe_run::probe @ /Users/allexoll/.cargo/registry/src/github.com-1ecc6299db9ec823/probe-run-0.3.1/src/probe.rs:33 (HOST) DEBUG started session └─ probe_run @ /Users/allexoll/.cargo/registry/src/github.com-1ecc6299db9ec823/probe-run-0.3.1/src/main.rs:80 (HOST) INFO flashing program (7 pages / 7.00 KiB) └─ probe_run @ /Users/allexoll/.cargo/registry/src/github.com-1ecc6299db9ec823/probe-run-0.3.1/src/main.rs:92 (HOST) DEBUG Erased sector of size 32768 bytes in 237 ms └─ probe_run @ /Users/allexoll/.cargo/registry/src/github.com-1ecc6299db9ec823/probe-run-0.3.1/src/main.rs:100 (HOST) DEBUG Programmed page of size 1024 bytes in 178 ms └─ probe_run @ /Users/allexoll/.cargo/registry/src/github.com-1ecc6299db9ec823/probe-run-0.3.1/src/main.rs:108 (HOST) DEBUG Programmed page of size 1024 bytes in 153 ms └─ probe_run @ /Users/allexoll/.cargo/registry/src/github.com-1ecc6299db9ec823/probe-run-0.3.1/src/main.rs:108 (HOST) DEBUG Programmed page of size 1024 bytes in 156 ms └─ probe_run @ /Users/allexoll/.cargo/registry/src/github.com-1ecc6299db9ec823/probe-run-0.3.1/src/main.rs:108 (HOST) DEBUG Programmed page of size 1024 bytes in 155 ms └─ probe_run @ /Users/allexoll/.cargo/registry/src/github.com-1ecc6299db9ec823/probe-run-0.3.1/src/main.rs:108 (HOST) DEBUG Programmed page of size 1024 bytes in 153 ms └─ probe_run @ /Users/allexoll/.cargo/registry/src/github.com-1ecc6299db9ec823/probe-run-0.3.1/src/main.rs:108 (HOST) DEBUG Programmed page of size 1024 bytes in 154 ms └─ probe_run @ /Users/allexoll/.cargo/registry/src/github.com-1ecc6299db9ec823/probe-run-0.3.1/src/main.rs:108 (HOST) DEBUG Programmed page of size 1024 bytes in 154 ms └─ probe_run @ /Users/allexoll/.cargo/registry/src/github.com-1ecc6299db9ec823/probe-run-0.3.1/src/main.rs:108 (HOST) INFO success! └─ probe_run @ /Users/allexoll/.cargo/registry/src/github.com-1ecc6299db9ec823/probe-run-0.3.1/src/main.rs:125 (HOST) DEBUG couldn't find valid stack range, not placing stack canary └─ probe_run::canary @ /Users/allexoll/.cargo/registry/src/github.com-1ecc6299db9ec823/probe-run-0.3.1/src/canary.rs:62 (HOST) DEBUG starting device └─ probe_run @ /Users/allexoll/.cargo/registry/src/github.com-1ecc6299db9ec823/probe-run-0.3.1/src/main.rs:183 Error: An error with the usage of the probe occured

Caused by: Operation timed out

**config.toml**

[target.thumbv7em-none-eabi] runner = "probe-run --chip LPC54608J512ET180 --speed 100 --verbose" rustflags = [ "-C", "link-arg=-Tlink.x", # required by cortex-m-rt "-C", "link-arg=-Tdefmt.x", # defmt logs "-C", "linker=flip-link", # stack overflow protection ]

[build]

cross compilation target = ARM Cortex-M4

target = "thumbv7em-none-eabi"

**Probe details**

``` console
$ probe-rs-cli list
The following devices were found:
[0]: LPC-LINK2 CMSIS-DAP V5.361 (VID: 1fc9, PID: 0090, Serial: NQATCQIQ, CmsisDap)

Operating System:

Mac OS 11.6.2

ELF file (attachment) gpio.zip

Additional context The message about having issues with the stack might be related to a quirk of this family of mcu where the SRAM is not turned on at boot. To address this, an asm blob containing a __pre_init symbol that turns on the ram when cortex-m-rt calls it is included at link time. I'm wondering at what point in the execution the program is halted to check the presence of the stack. if that is done at reset time, it wont work, but if it's done at cortex_m_rt::entry it should.

happy to test things if need be

[allexoll]

Found multiple issues with my bootstraping, closing the issue.

200KB of sram does not mean 200KB of SRAM0, but 160 KB of SRAM0 + 32KB of SRAMX + 8KB of USB RAM, so the top of the stack was out of memory range.

and i used write(|w|...) instead of modify early in main on the same register that turns on the SRAM, effectively turning it off as well. works otherwise, sorry for the issue.

Best regards

[Urhengulas]

I just started to look into it, but good to see that you could solve your issue yourself! 👏🏽

Is there anything how our tooling could have helped.you to spot the problem earlier?

Best, Johann

[allexoll]

I don't think so, this was just a bootstrapping issue, thanks for asking!

Best regards

[jonas-schievink]

If the memory maps in probe-rs are reasonably accurate, we could warn if the initial stack pointer is not in (or one address past) one of the RAM regions.

[allexoll]

That would have caught it, but I'm unsure how that could work with devices that also have external memory controllers (as this family has), where the memory.x might be different from the memory-map in probe-rs/targets, although that could be addressed by #291 too, with custom target definition.