Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
Problem: On the CM4 CPU, some code in main() executes before the debugger halts at the beginning of main(). This means that some code executes twice - before the debugger halts execution, and again after the debugger resets the program counter to the beginning of main().
Background:This problem affects only debugging. The debugger's process for acquiring the target takes time. The debugger resets the target and then halts the application on the CM4 CPU. After reset and before halting, there is enough time that some code in main() executes. The debugger puts the program counter at the first line of main(). When you start debugging, some code executes a second time.
This multiple execution is frequently invisible. If the code at the start of main() prints information to a terminal window, you may see the print commands appear twice, revealing this issue.
Typically, repeated execution does not cause problems, but it can. For example, assume that the code tests for and sets a flag. The second time the code executes, if that flag is in a different state, the code may behave differently. This is the same effect you see if you manually move the program counter to re-execute some code while debugging.
Solution:If multiple execution of the CM4 CPU main() function is an issue for your code, the simple workaround is to put a delay loop at the beginning of the code. This prevents sensitive code from executing twice. The length of the required delay varies based on the nature of your debug environment (IDE, probe, and so forth). The snippet below uses a delay of 400 milliseconds, which is usually sufficient for the Eclipse IDE for ModusToolbox. The delay required in your environment may be longer or shorter.
/* If an active debugger is detected, give it some time to execute SYSRESETREQ
* otherwise, the application runs before the debugger is fully operational */
if (CoreDebug->DHCSR & CoreDebug_DHCSR_C_DEBUGEN_Msk)