search

esp-rs / esp-backtrace

backtrace for ESP32 bare-metal
Apache License 2.0
29 stars 10 forks source link

Extend `is_valid_ram_address` to LP (RTC) memories #27

Closed MabezDev closed 1 year ago

MabezDev commented 1 year ago

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

MabezDev commented 1 year ago

You might get a stack trace in this region if you call a function that's placed in this ram region, e.g: https://github.com/esp-rs/esp-hal/blob/edd6c16637f9639c2e4de9f7c664c398794c2594/esp32c3-hal/examples/ram.rs#L94-L97

bjoernQ commented 1 year ago

IIRC is_valid_ram_address is only used to check the stack frame address - not the program counter address. I tested with a panic inside function_in_rtc_ram on C3 and S3 and I got the backtrace.

Do you have an example where it failed to produce a backtrace while it should be able to generate it?

MabezDev commented 1 year ago

I don't have a concrete case, because I was just theorizing that it was possible :D. I think the case I had in my mind was if function_in_rtc_ram called another function inside rtc ram. I think then you'd get a stacktrace which was partially in rtc ram?

bjoernQ commented 1 year ago

Should work - at least in my test it does: (tested on ESP32-S3 but shouldn't matter)

0x420179a3 - core::panicking::panic
    at C:\Users\Bjoern\.rustup\toolchains\esp\lib\rustlib\src\rust\library\core\src\panicking.rs:117
0x42001e59 - ram::in_flash
    at C:\projects\esp\esp-hal\esp32s3-hal\examples\ram.rs:101
0x600fe00d - ram::function_in_rtc_ram
    at C:\projects\esp\esp-hal\esp32s3-hal\examples\ram.rs:96
0x420027f1 - ram::__xtensa_lx_rt_main
    at C:\projects\esp\esp-hal\esp32s3-hal\examples\ram.rs:81
0x42015193 - Reset
    at C:\Users\Bjoern\.cargo\registry\src\index.crates.io-6f17d22bba15001f\xtensa-lx-rt-0.16.0\src\lib.rs:70
0x403787cf - ESP32Reset
MabezDev commented 1 year ago

Nice, in which case we can close this! Thanks for looking into it :).