UDF misreported as "program panicked"

japaric commented 3 years ago

STR

Start from app-template and create a src/bin/udf.rs file that contains this main function

fn main() -> ! {
    cortex_m::asm::udf()
}

$ cargo rb udf
   7: Reset
        at /home/japaric/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-rt-0.6.13/src/lib.rs:550
  (HOST) ERROR the program panicked

Output is incorrect because the program didn't panicked. A hard fault != panic.

panic_probe uses UDF to terminate the probe-run process so right now we classify 'hit UDF' as 'program panicked' but this is not accurate.

Ideally we want "program panicked" if panic-probe was used and the program panicked and "program hit a hard fault exception" otherwise

Urhengulas commented 1 year ago

Open question: How to differentiate a panic from a hard fault?

Urhengulas commented 1 year ago

Detecting the hard fault

When your system is hung up, the first step is to detect the cause for the hang up. To detect the cause for system hang up, first execute your program in debugging mode and allow the system to run until the system hangs up again, then halt the debugger. There are two ways to determine whether the hang up is due to the hard fault. The first is to watch the Program Counter (PC) register. If this is a hard fault, the PC register will indicate operation in the hard fault handler. The second method is to watch the Interrupt Program Status Register (IPSR). A value of 0x3 indicates a hard fault.

(https://www.embedded.com/debugging-hard-faults-in-arm-cortex-m0-based-socs/)

knurling-rs / probe-run

UDF misreported as "program panicked" #195

STR