In my Cortex M7 based project I am in a condition where often a reset takes place apparently for no reason. The only thing I can think of is that there has been a lockup.If I have a breakpoint at the first instruction of the Handler Reset is it possible then to know the cause of the lockup? In other words, how can I debug the lockup after the reset has taken place?
Best regards
Max
That gives me hope. My CMSIS sources are given to me by NXP within their SDK. The latest version of the SDK incorporates CMSIS v5.0.5 from January 2018.
The code to enable cache is:
/* Enable instruction and data caches */ #if defined(__ICACHE_PRESENT) && __ICACHE_PRESENT if (SCB_CCR_IC_Msk != (SCB_CCR_IC_Msk & SCB->CCR)) { SCB_EnableICache(); } #endif #if defined(__DCACHE_PRESENT) && __DCACHE_PRESENT if (SCB_CCR_DC_Msk != (SCB_CCR_DC_Msk & SCB->CCR)) { SCB_EnableDCache(); } #endif
This is the only lines where cache is mentioned before the crash.
I tried to comment these lines, so if ROM bootloader enables cache, no one else will reenable them; otherwise if ROM Bootloader doesn't enable the cache it will run without them. Slowly but this avoid the bug, I hope.
Unfortunately the crash still happens.
best regards
>Unfortunately the crash still happens.
hmm.... have you tried increase the size of stack to see if there is a stack overflow problem?
Otherwise, breakpoint and bisectioning is possibly the easiest solution given that you don't have instruction trace.
(In case you want to get hold of the latest CMSIS release you can find it on
https://github.com/ARM-software/CMSIS_5/releases )
regards,
Joseph