Skip to content
This repository has been archived by the owner on Jan 30, 2024. It is now read-only.

Stack Overflow using J-Link in CMSIS-DAP mode with RP2040 #359

Open
sigmaris opened this issue Oct 8, 2022 · 1 comment
Open

Stack Overflow using J-Link in CMSIS-DAP mode with RP2040 #359

sigmaris opened this issue Oct 8, 2022 · 1 comment
Labels
type: bug Something isn't working

Comments

@sigmaris
Copy link

sigmaris commented Oct 8, 2022

Describe the bug
I am trying to flash and run an ELF based on the RP2040 project template to an W5500-EVB-Pico board, using a J-Link EDU probe. The board is identical to the RP Pico board but additionally has a WizNet W5500 Ethernet chip on the RP2040's SPI interface, but that shouldn't affect debugging. Due to probe-rs/probe-rs#1157 it isn't possible using the J-Link 'native' mode, but the probe can be reconfigured to support CMSIS-DAP mode, so I've done this and am attempting to use it with probe-run.

To Reproduce

  1. Connect J-Link EDU probe (J-Link EDU V11.00, firmware version '2022 Sep 22 14:53') via USB and use Segger's JLinkConfig application to configure it in CMSIS-DAP mode instead of the native J-Link mode.
  2. Identify the probe by serial number using probe-run --list-probes:
the following probes were found:
[0]: J-Link CMSIS-DAP (VID: 1366, PID: 1008, Serial: 000261003501, CmsisDap)
[1]: J-Link (VID: 1366, PID: 1008, JLink)
  1. Connect probe to Pico board and try to flash and run the attached ELF using the command probe-run --chip RP2040 --probe 000261003501 --verbose target/thumbv6m-none-eabi/debug/rp2040-project-template

Expected and observed behavior
I expected the ELF to be run on the RP2040, but probe-run itself crashes with the message

(HOST) DEBUG vector table: VectorTable { initial_stack_pointer: 2003fa98, hard_fault: 10010eed }
└─ probe_run::elf @ /Users/hugh/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/probe-run-0.3.5/src/elf.rs:31
(HOST) DEBUG RAM region: 0x20000000-0x2003FFFF
└─ probe_run::target_info @ /Users/hugh/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/probe-run-0.3.5/src/target_info.rs:115
(HOST) DEBUG section `.data` is in RAM at 0x2003FA98..=0x2003FADF
└─ probe_run::target_info @ /Users/hugh/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/probe-run-0.3.5/src/target_info.rs:153
(HOST) DEBUG section `.bss` is in RAM at 0x2003FAE0..=0x2003FBFB
└─ probe_run::target_info @ /Users/hugh/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/probe-run-0.3.5/src/target_info.rs:153
(HOST) DEBUG section `.uninit` is in RAM at 0x2003FBFC..=0x2003FFFB
└─ probe_run::target_info @ /Users/hugh/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/probe-run-0.3.5/src/target_info.rs:153
(HOST) DEBUG valid SP range: 0x20000000..=0x2003FA94
└─ probe_run::target_info @ /Users/hugh/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/probe-run-0.3.5/src/target_info.rs:167
(HOST) DEBUG found 1 probes
└─ probe_run::probe @ /Users/hugh/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/probe-run-0.3.5/src/probe.rs:25
(HOST) DEBUG opened probe
└─ probe_run::probe @ /Users/hugh/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/probe-run-0.3.5/src/probe.rs:33

thread 'main' has overflowed its stack
fatal runtime error: stack overflow
[1]    26356 abort      probe-run --chip RP2040 --probe 000261003501 --verbose```

I've attached the full macOS problem report with stack trace:
problemreport.txt

config.toml

[target.'cfg(all(target_arch = "arm", target_os = "none"))']
# Choose a default "cargo run" tool:
# - probe-run provides flashing and defmt via a hardware debugger
# - cargo embed offers flashing, rtt, defmt and a gdb server via a hardware debugger
#     it is configured via the Embed.toml in the root of this project
# - elf2uf2-rs loads firmware over USB when the rp2040 is in boot mode
runner = "probe-run --chip RP2040"
# runner = "cargo embed"
# runner = "elf2uf2-rs -d"

rustflags = [
  "-C", "linker=flip-link",
  "-C", "link-arg=--nmagic",
  "-C", "link-arg=-Tlink.x",
  "-C", "link-arg=-Tdefmt.x",

  # Code-size optimizations.
  #   trap unreachable can save a lot of space, but requires nightly compiler.
  #   uncomment the next line if you wish to enable it
  # "-Z", "trap-unreachable=no",
  "-C", "inline-threshold=5",
  "-C", "no-vectorize-loops",
]

[build]
target = "thumbv6m-none-eabi"

[env]
DEFMT_LOG = "debug"

Probe details

$ probe-rs-cli list
The following devices were found:
[0]: J-Link CMSIS-DAP (VID: 1366, PID: 1008, Serial: 000261003501, CmsisDap)
[1]: J-Link (VID: 1366, PID: 1008, JLink)

ELF file
rp2040-project-template.zip

Operating System:
macOS 12.6 x86_64

@Urhengulas Urhengulas added the type: bug Something isn't working label Jan 10, 2023
@Urhengulas
Copy link
Member

Urhengulas commented Feb 5, 2023

Hi @sigmaris, interesting problem. From your logs it seems that the issue occurs somewhere here:

probe-run/src/main.rs

Lines 62 to 86 in 80ab018

let probe = probe::open(opts)?;
let probe_target = target_info.probe_target.clone();
let mut sess = if opts.connect_under_reset {
probe.attach_under_reset(probe_target, Permissions::default())?
} else {
let probe_attach = probe.attach(probe_target, Permissions::default());
if let Err(probe_rs::Error::Probe(ProbeSpecific(e))) = &probe_attach {
// FIXME Using `to_string().contains(...)` is a workaround as the concrete type
// of `e` is not public and therefore does not allow downcasting.
if e.to_string().contains("JtagNoDeviceConnected") {
eprintln!("Info: Jtag cannot find a connected device.");
eprintln!("Help:");
eprintln!(" Check that the debugger is connected to the chip, if so");
eprintln!(" try using probe-run with option `--connect-under-reset`");
eprintln!(" or, if using cargo:");
eprintln!(" cargo run -- --connect-under-reset");
eprintln!(" If using this flag fixed your issue, this error might");
eprintln!(" come from the program currently in the chip and using");
eprintln!(" `--connect-under-reset` is only a workaround.\n");
}
}
probe_attach?
};
log::debug!("started session");

The last log statement ((HOST) DEBUG opened probe) is emitted at the end of probe::open and the log statement which would be shown next ((HOST) DEBUG opened probe) is not being shown as the stack overflow happens before.

As you don't use the --connect-under-reset option the most likely place the error can come from is the probe.attach(probe_target, Permissions::default()).

Now the question is why this causes the stack overflow 🤔 I will try to reproduce.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants