Capturing stack fails, calculating stack_size too big. #32
Comments
|
Panic handler #[defmt::panic_handler]
fn panic() -> ! {
cortex_m::interrupt::free(|_cs| {
unsafe {
stackdump_capture::cortex_m::capture(
&mut *STACK_CAPTURE.as_mut_ptr(),
&mut *CORE_REGISTERS_CAPTURE.as_mut_ptr(),
&mut *FPU_REGISTERS_CAPTURE.as_mut_ptr(),
);
// If you want to capture the heap or the static data, then do that here too yourself
}
set_capture_made();
});
cortex_m::peripheral::SCB::sys_reset(); //panic_reset
//cortex_m::asm::udf() //panic_probe
}Cargo tree |
|
Hi! Thanks for the elaborate info! From the cargo tree I saw you're running an nRF52840. I've used this crate on that, so in principle it should work. Here are your registers decoded: In red we see you have a stackpointer of 0x2003b698 which seems reasonable for your chip. The math checks out and the values I can see from what you've given me seem good. So my guess is that the debugger displays you a wrong value for the stack size. But what's the actual problem? Does it crash for you? |
|
Yes, the stack_start is 0x20040000. In my case, the application does not crash, but I can not print the STACK_CAPTURE through defmt. The issue I encountered was that when this code is ran when a capture was made: if is_capture_made() {
reset_capture_made();
info!("STACKCAPTURE {=[u8]:x}", unsafe {
STACK_CAPTURE
.assume_init_ref()
.bytes()
.collect::<Vec<u8, 0x4000>>()
});
info!("CORECAPTURE {=[u8]:x}", unsafe {
CORE_REGISTERS_CAPTURE
.assume_init_ref()
.bytes()
.collect::<Vec<u8, 128>>()
});
info!("FPUCAPTURE {=[u8]:x}", unsafe {
FPU_REGISTERS_CAPTURE
.assume_init_ref()
.bytes()
.collect::<Vec<u8, 256>>()
});The output is this: I never get the first info!, not even an empty array or similiar. |
|
Well, it seems that defmt might sometimes now show messages that overwhelm its resources. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
When stack capture is created, the stack_size is calculated. Debugging our project I see that this is calculated to be 536875968, which is rather large, and seems to rather be a memory address, 0x200013c0.
Story
So I realized that I cannot print the stack capture on start, but fpu and core registers are fine with this:
Then I tried to debug the issue, (but debug itself became the issue, then we solved that) and saw that stack_size value turns out to be something resembling a memory address.
The issue is that I still can't debug in opt = 0 , therefore cannot follow what is going wrong there.
Some data (will provide)
The text was updated successfully, but these errors were encountered: