On Sun, Feb 21, 2021 at 11:18 AM Gregory Nutt <spudan...@gmail.com> wrote: > A breakpoint on up_assert should catch any early crashes as you > describe. There is a cool debug tip here if you hit the breakpoint: > *https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf*
Unfortunately that appears to be a broken link now. However, the cool debug tip that Greg is referring to is, I think, the following... (I have this written in my notes from a previous hard-fault debugging session.) Note that it is applicable to ARM -- you may need to adjust for MIPS. * Set up breakpoints at up_hardfault() and up_assert(). * When the breakpoint is reached, set the PC (program counter register) equal to the LR (holds the return address for a function call). * Switch to assembly view. * Single-step (by assembly instructions) to the "bx lr" instruction in do_irq(). That should take you to the line of code where the hard fault occurred. A few more thoughts: On ARM platforms, one of the common causes of hard faults is forgetting to turn on the clocking to a peripheral and then trying to access that peripheral. I haven't worked with PIC32 in a few years but I seem to recall that any hard faults I experienced there were caused by unaligned accesses. Hope this helps, Nathan
