PIC32are MPS and do not have hardfaults. That is a Cortex-M thing. So
DSidranes tip does not apply and up_hardfault should not exist for
PIC32. I spend too much time with ARMs and a forget about the rest of
the world.
So nevermind... sorry.
On 2/21/2021 5:11 PM, Nathan Hartman wrote:
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
