-
Bug
-
Resolution: Fixed
-
High
-
Code Composer Studio Debugger
-
CCBT-2949
-
CCS_10.4.0
-
CCS_11.0.0
-
Generic
-
Explicitly use hardware breakpoints instead of software breakpoints
During the A53 SMP debug session of an example RTOS application on an AM6548, CPU1 appears to get “stuck” at a specific address. Any attempt to run, step, etc has no effect as the CPU will still remain halted at the same address (0x70002154) inside the uart_task function.
The issue is an odd one as it seems to only occur when the CPU is halted (via breakpoint) before the uart_task function is called. When stepping over it, it seems to get stuck and the target seems to get into a bad state.
If target is run without the breakpoint, the program runs as expected with no issues.
There are a lot of considerations here. SMP debug is involved. The memory is configured as "shared" but perhaps some other configuration is missing. Also the issue could be that the target got into a bad state instead of a specific debugger issue. In any case, more investigation is required to determine the root cause.
UPDATE: It appears that the issue is specific to software breakpoints during SMP debug of code in shared memory. The specific address does not matter. The issue occurs after a software breakpoint is triggered and then some single stepping occurs afterwards.