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
None of the documents related to RT1051 refers to ETB, but only to ETM.
Joseph Yiu said:Do you mean the system crash right after getting into beginning of main()? (the description is not very clear).
I'll try to explain better: the SOC RT1051 has a ROM bootloader (whose code is written by NXP and is obviously closed). At reset resetISR in ROM bootloader is executed. Then, after all the work the ROM bootloader does, the execution jumps into my startup code, which copies .data to RAM and resets .bss. WDTs are turned off and caches enabled, and then execution jumps to the main(). The main() enables faults and calls the function to initialize the multiplexing of GPIO pins and ports. This function is never exited. But going into assembler step-by-step debug everything works, so the only way I have to debug is to impose breakpoints by bisectioning the code.
So the crash happens many instructions after entering the main().
best regrads
Thanks.
How do you initialize the caches? There was a bug with the core_cm7.h that if the D cache has been initialized, and if the D-cache initialization function get call again it could cause a crash. That was fixed in CMSIS 5 github in Oct 2018.
regards,
Joseph
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 )