The easiest way to debug a lockup reset on RT1051

[mastupristi]

In my RT1051 based project I am in a condition where often a reset takes place apparently for no reason.

in my code I have the enabling of faults and the code to analyze them, as explained here:

https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html

I have the fault enabled:

 SCB->SHCSR |= SCB_SHCSR_USGFAULTENA_Msk
    |  SCB_SHCSR_BUSFAULTENA_Msk
    |  SCB_SHCSR_MEMFAULTENA_Msk; // enable Usage-, Bus-, and MMU Fault
‍‍‍

I have no watchdog active, however the core is reset.
The SRC->SRSR register tells me that the reset was done by lockup (I'm pretty sure that a SYSRESETREQ is never triggered). It happens quite early, after the startup code has populated the .data section and reset .bss in RAM. Then it jumps to the main(), and the first function it calls (BOARD_InitPins(), to set pins and their multiplexing) does not exit. The things that are done within this function are mostly repetitive, and it fails about halfway. So I would like to understand what kind of event caused the lockup without (apparently) raising faults.

Is there a way to debug this?

best regards

Max

[jingpan]

Hi,

The ARMv7-M architecture generally assumes that, when the processor is running at priority -1 or higher,
any fault or supervisor call that occurs is entirely unexpected and fatal.
The standard exception entry mechanism does not apply where a fault or supervisor call occurs at a priority
of -1 or above. ARMv7-M requires the processor to handle most of these cases using a lockup mechanism.
Other cases become pending or are ignored. Lockup means the processor suspends normal instruction
execution and enters Lockup state.

The detail explanation of lockup is in DDI0403D_arm_architecture_v7m_reference_manual.pdf. You can download it from ARM website. There is also M4/M3 lockup explanation in below link. It seems they are similar.

https://community.nxp.com/message/1101536?commentID=1101536#comment-1101536 

You said that the lockup happened in BOARD_InitPins(). I guess the problem is caused by clock enable or error register access or conflict setting. You can step into the function to see which step cause problem.

Regards,

Jing