esp-rs / esp-backtrace Goto Github PK

backtrace for ESP32 bare-metal

License: Apache License 2.0

Rust 100.00%

esp-backtrace's Issues

`colors` features not compatible with `panic-handler` feature

 1  error[E0425]: cannot find value `RED` in this scope
   --> /home/ripytide/.cargo/registry/src/index.crates.io-6f17d22bba15001f/esp-backtrace-0.10.0/src/lib.rs:48:20
    |
 48 |     set_color_code(RED);
    |                    ^^^ not found in this scope

 2  error[E0425]: cannot find value `RESET` in this scope
   --> /home/ripytide/.cargo/registry/src/index.crates.io-6f17d22bba15001f/esp-backtrace-0.10.0/src/lib.rs:92:20
    |
 92 |     set_color_code(RESET);
    |                    ^^^^^ not found in this scope

 3  error[E0425]: cannot find value `RED` in this scope
    --> /home/ripytide/.cargo/registry/src/index.crates.io-6f17d22bba15001f/esp-backtrace-0.10.0/src/lib.rs:101:20
     |
 101 |     set_color_code(RED);
     |                    ^^^ not found in this scope

 4  error[E0425]: cannot find value `RESET` in this scope
    --> /home/ripytide/.cargo/registry/src/index.crates.io-6f17d22bba15001f/esp-backtrace-0.10.0/src/lib.rs:122:20
     |
 122 |     set_color_code(RESET);
     |                    ^^^^^ not found in this scope

 For more information about this error, try `rustc --explain E0425`.
 error: could not compile `esp-backtrace` (lib) due to 4 previous errors

Adapt to changed ESP32-C3 trap frame

In esp-rs/esp-hal#207 the trap frame struct changed. We should adapt our copy of the trap frame struct here.

Nothing bad should happen if we keep it like this so it's not an urgent task

backtrace printings

May be I'm wrong but I cannot really understand the next code fragment in lib.rs:98

        #[cfg(all(feature = "colors", feature = "println"))]
        println!("{}0x{:x}", RED, addr - crate::arch::RA_OFFSET);

!!!!! #[cfg(not(any(feature = "colors", feature = "println")))]
println!("0x{:x}", addr - crate::arch::RA_OFFSET);

If it wants to differentiate between the "colors" and not "colors" scenario, I think it's wrong. The second #[cfg... gives false in case of no"colors", printing nothing in that case.

I think the proper #[cfg... would be:

        #[cfg(all(not(feature = "colors"), feature = "println"))]
        println!("0x{:x}", addr - crate::arch::RA_OFFSET);

But I'm quite a newbie, so may be I'm wrong and misunderstood something.

Halt all cores in case of a panic (on multi core targets)

Currently if a panic occurs the core on which the panic occurred will run an infinite loop but other cores will happily continue to run - that will definitely cause problems

So, what we should do in the panic-handler is halting all cores - probably also the ULPs

Question: Should this be a (default) feature or is this always desired?

Prefix exception handler values with '0x'

espflash's monitor doesn't pick up on the exception values and doesn't print a backtrace 😢.

Document that `"-C", "force-frame-pointers"` is only necessary on RISCV targets

CC @MabezDev

started using this crate today after it got pulled in by the no_std application template. I see that currently it just debug-prints the PanicInfo, but would you accept a PR that adds some prettier formatting around it?

In a minimal esp32 code that prints "Hello" and then panics, the serial output is pretty crowded imo:

load:0x3fff0054,len:4800
load:0x40078000 [_stack_end_cpu0:??:??],len:17448
load:0x4007c428 [_stack_end_cpu0:??:??],len:4840
entry 0x4007c6a0 [_stack_end_cpu0:??:??]
Hello
PanicInfo { payload: Any { .. }, message: Some(Help me, I'm dying!), location: Location { file: "src/main.rs", line: 30, col: 9 }, can_unwind: true }
0x400d1bb8 [half_duplex_uart::__xtensa_lx_rt_main:/var/home/ahartmann/repos/mt/playground/half-duplex-uart/src/main.rs:30]
0x400d5816 [Reset:/usr/local/share/cargo/registry/src/github.com-1ecc6299db9ec823/xtensa-lx-rt-0.13.0/src/lib.rs:77]
0x400d29af [ESP32Reset:/usr/local/share/cargo/git/checkouts/esp-hal-42ec44e8c6943228/6e037b0/esp32-hal/src/lib.rs:78]

I was thinking about maybe something like this:

load:0x3fff0054,len:4800
load:0x40078000 [_stack_end_cpu0:??:??],len:17448
load:0x4007c428 [_stack_end_cpu0:??:??],len:4840
entry 0x4007c6a0 [_stack_end_cpu0:??:??]
Hello

!! A panic occured at "src/main.rs", line 30, column 9

  Message: Help me, I'm dying!
  Payload: ??
Backtrace:

0x400d1bb8 [half_duplex_uart::__xtensa_lx_rt_main:/var/home/ahartmann/repos/mt/playground/half-duplex-uart/src/main.rs:30]
0x400d5816 [Reset:/usr/local/share/cargo/registry/src/github.com-1ecc6299db9ec823/xtensa-lx-rt-0.13.0/src/lib.rs:77]
0x400d29af [ESP32Reset:/usr/local/share/cargo/git/checkouts/esp-hal-42ec44e8c6943228/6e037b0/esp32-hal/src/lib.rs:78]

Or in accordance with the default rust panic handler:

!! A panic occured at src/main.rs:30:9

Give a hint if there are no backtrace entries on RISCV

To make backtraces work on RISCV the user needs to force frame-pointers.
We can give a hint in case there are no backtrace entries when running on a RISCV target instead of printing nothing

Extend `is_valid_ram_address` to LP (RTC) memories

At the moment if we have part of the backtrace in LP memory esp-backtrace will fail.

file not found for module `arch`

Hi, When I run cargo run, it reports this error！

error[E0583]: file not found for module `arch`
 --> /Users/xxx/.cargo/registry/src/mirrors.ustc.edu.cn-61ef6e0cd06fb9b8/esp-backtrace-0.7.0/src/lib.rs:8:1
  |
8 | pub mod arch;
  | ^^^^^^^^^^^^^
  |
  = help: to create the module `arch`, create file "/Users/xxx/.cargo/registry/src/mirrors.ustc.edu.cn-61ef6e0cd06fb9b8/esp-backtrace-0.7.0/src/arch.rs" or "/Users/xxx/.cargo/registry/src/mirrors.ustc.edu.cn-61ef6e0cd06fb9b8/esp-backtrace-0.7.0/src/arch/mod.rs"

error[E0425]: cannot find function `backtrace` in module `crate::arch`
  --> /Users/xxx/.cargo/registry/src/mirrors.ustc.edu.cn-61ef6e0cd06fb9b8/esp-backtrace-0.7.0/src/lib.rs:31:34
   |
31 |     let backtrace = crate::arch::backtrace();
   |                                  ^^^^^^^^^ not found in `crate::arch`

Some errors have detailed explanations: E0425, E0583.
For more information about an error, try `rustc --explain E0425`.
error: could not compile `esp-backtrace` (lib) due to 2 previous errors

Add a feature for logging panics with defmt

In line with the print-uart and print-rtt features, perhaps a print-defmt would make sense?

I am happy to submit a PR for this, however I have a question. The current implementation calls several println!() functions. In most defmt log printers, the contents of the log statement gets printed along with the location in the source code that the log statement was called.

Would this mean that we would have only one error!() invocation in the panic_handler? Or should we still call error!() each time we call println().

Also, due to this quirk of defmt vs println style printing, should I add this functionality to esp-println? Because it may be a mismatch of expected output format.

esp-rs / esp-backtrace Goto Github PK

esp-backtrace's Issues

`colors` features not compatible with `panic-handler` feature

Adapt to changed ESP32-C3 trap frame

backtrace printings

Add support for the ESP32-C6

Halt all cores in case of a panic (on multi core targets)

Prefix exception handler values with '0x'

Add support for the ESP32-H2

Document that `"-C", "force-frame-pointers"` is only necessary on RISCV targets

Prettier panic formatting?

Give a hint if there are no backtrace entries on RISCV

Extend `is_valid_ram_address` to LP (RTC) memories

file not found for module `arch`

Add a feature for logging panics with defmt

Add support for the ESP32-P4

Sleep modes? Are they available? How can I put my esp32 to deep sleep?

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

Jobs