We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
From "I2.2.2 Halt-on-debug", When the CNTCR.HDBG bit is set to 1, and the Halt-on-debug signal is implemented and asserted, the system counter is halted. Otherwise, the system counter ignores the state of this signal.
What are the practical use cases for pausing the system counter through an external debugger? When is it necessary to pause the counter through cross-triggering?
Let's assume one scenario in a multi PE system, if one core is halted by the debugger while the system counter ( or global timer or system timer in other naming conventions ) continues to increase, if the halted core was involved in time-sensitive tasks or synchronization with other cores, halting it could lead to inconsistencies or race conditions, as the other cores continue to operate and the system counter keeps incrementing.
Therefore, when multiple PEs are executing time-sensitive tasks simultaneously, if an external debugger halts one PE, does it need to also halt the system counter to ensure the correctness of timing?
However, would the other PEs that are still running be unable to obtain the correct time from the system counter because it has been halted?
Typically, the debugger only halts one core, other cores can execute instruction normally and system counter can increase normally.
For the halted core, it will take the risk I described in above.
Let me understand. In multi-core time-sensitive task scenarios, for the halted core, it is necessary to synchronously halt the global counter to ensure time synchronization.However, once the global counter is halted, will it also affect other cores that are running normally?
It will affect other cores if the global counter is halted.
So the developer should know and balance the debugger impact vs the debugger actions he will take.