It would be nice to have a panic handler that does the following. I wanted to see if you think this made sense for panic-ramdump, or whether I should make a separate crate.
Force the user to define a memory section for a ramdump, maybe something like 1k. This should be doable from memory.x. This section should not be zeroed as part of BSS.
On panic, write a magic word to the start of this section, followed by the length of the panic message, e.g. (min(remaining size, panic message len)) then use the remainder of the space to store the panic message. The device should then soft reset, e.g. like the panic-reset crate.
The crate should also provide a function that returns something like Option<&'static str>. If the magic word is present in RAM, it should return the length-prefixed panic message as a &str slice
This would enable crates to determine/report the panic message on a soft reboot, or perhaps even detect a cold boot (or at least a reboot that didn't preserve RAM).
I quite like this! Would be quite good when not having a full blown panic handler such as semihosting or ITM, but still get messages out in whatever is the preferred way.
It would be nice to have a panic handler that does the following. I wanted to see if you think this made sense for
panic-ramdump
, or whether I should make a separate crate.memory.x
. This section should not be zeroed as part of BSS.min(remaining size, panic message len)
) then use the remainder of the space to store the panic message. The device should then soft reset, e.g. like thepanic-reset
crate.Option<&'static str>
. If the magic word is present in RAM, it should return the length-prefixed panic message as a &str sliceThis would enable crates to determine/report the panic message on a soft reboot, or perhaps even detect a cold boot (or at least a reboot that didn't preserve RAM).
CC @korken89