Extend `is_valid_ram_address` to LP (RTC) memories about esp-backtrace

[MabezDev]

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]

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]

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]

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]

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