STM32F407VGTx Do not have unwind info for the given address about probe-run

[jacobrosenthal]

Seems like thats gimli? maybe here

probe-run/src/main.rs

Line 483 in a23c6b4

let fde = debug_frame.fde_for_address(bases, pc.into(), DebugFrame::cie_from_offset)?;

[japaric]

Forgot to document this: when you use the release profile you need to set debug = 1 (or higher) in the crate/workspace Cargo.toml. This is the default in the cortex-m-quickstart template but if you are using something else you'll need to set it manually. Could you check that @jacobrosenthal ? If release still doesn't work; does the dev profile work?

[jacobrosenthal]

I did not. However it didnt seem to help (true, nor 2), nor did dev mode.

[japaric]

Next thing that can fail is non-Rust subroutines w/o CFI information, e.g. external assembly (old releases of cortex-m have this issue) or C code. Could you check that cortex-m is set to latest version (0.6.3) in Cargo.lock? Also do you have C dependencies?

Given that this fails in the very first frame then it's likely external assembly. Could you disassembly the ELF to see which routine contains the 0x0800132e address? Given your example the commands would be:

$ # rust-objdump is part of the `cargo-binutils` crate
$ rust-objdump -Cd target/thumbv7em-none-eabi/release/examples/cycle_count

Then look for the address that appears in the first frame of the backtrace ( 0x0800132e in the example). You should see something like this:

00000e8a __bkpt:
     e8a: 00 be                         bkpt    #0
     e8c: 70 47                         bx      lr

^ That's an example with the wrong address but we'd like to identify the subroutine that's causing problems (in the example above it would be __bkpt for address 0x00000e8a).

Alternatively, you can point me to the source code of the program that's giving you issues but I'll need the exact Cargo.lock and Cargo.toml files you are using plus the updated error message with command line invocation to diagnose the error.

[jacobrosenthal]

I had 0.6.2 updating to 0..6.3 seems to have fixed it. ``` flashing program .. DONE resetting device ticks: 16800007 stack backtrace: 0: 0x08001618 - __bkpt 1: 0x0800067a - cycle_count::__cortex_m_rt_main 2: 0x08000464 - main 3: 0x0800113a - Reset ```

…

On Mon, Aug 17, 2020 at 12:01 AM Jorge Aparicio ***@***.***> wrote: Next thing that can fail is non-Rust subroutines w/o CFI information, e.g. external assembly (old releases of cortex-m have this issue) or C code. Could you check that cortex-m is set to latest version (0.6.3) in Cargo.lock? Also do you have C dependencies? Given that this fails in the very first frame then it's likely external assembly. Could you disassembly the ELF to see which routine contains the 0x0800132e address? Given your example the commands would be: $ # rust-objdump is part of the `cargo-binutils` crate $ rust-objdump -Cd target/thumbv7em-none-eabi/release/examples/cycle_count Then look for the address that appears in the first frame of the backtrace ( 0x0800132e in the example). You should see something like this: 00000e8a __bkpt: e8a: 00 be bkpt #0 e8c: 70 47 bx lr ^ That's an example with the wrong address but we'd like to identify the subroutine that's causing problems (in the example above it would be __bkpt for address 0x00000e8a). Alternatively, you can point me to the source code of the program that's giving you issues but I'll need the exact Cargo.lock and Cargo.toml files you are using plus the update error message with command line invocation to diagnose the error. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADPI5FDLPEHIOXL76WU2T3SBDITPANCNFSM4QBADPFQ> .

[japaric]

Thanks for checking! Will improve the error message and add some notes to the docs.