You can try the section on hardfault debugging here:
https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf That
starts at slide 17:
/Set a breakpoint on up_hardfault and up_assert//Set the PC equal to
the LR//Select assembly single step//And step to bx lr instruction
in do_irq that will return you to the line of code //that caused the
HardFault/
On 11/23/2020 3:07 PM, Nathan Hartman wrote:
Some months ago I implemented the basic architectural support for
STM32G47xxx and I noticed that occasionally, during startup, I am
getting stuck in _up_assert(). It is not happening consistently. It's
intermittent. I'm not really sure why. Any ideas what I should look
for? Here is the backtrace:
Program received signal SIGINT, Interrupt.
_up_assert () at armv7-m/arm_assert.c:353
(gdb) backtrace
#0 _up_assert () at armv7-m/arm_assert.c:353
#1 0x0800e2e4 in up_assert (filename=0x8013bc8
"armv7-m/arm_hardfault.c", lineno=134) at armv7-m/arm_assert.c:428
#2 0x080092e2 in _assert (filename=0x8013bc8
"armv7-m/arm_hardfault.c", linenum=134) at assert/lib_assert.c:36
#3 0x08000fb8 in arm_hardfault (irq=3, context=0x20001754, arg=0x0)
at armv7-m/arm_hardfault.c:134
#4 0x08004d7c in irq_dispatch (irq=3, context=0x20001754) at
irq/irq_dispatch.c:183
#5 0x08000b80 in arm_doirq (irq=3, regs=0x20001754) at armv7-m/arm_doirq.c:71
#6 0x08000b02 in exception_common () at armv7-m/gnu/arm_lazyexception.S:208
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Thanks,
Nathan
