hello
I am trying to implement breakpoint operation in source code using cortex-R5F.
There are some problems during implementation.
I enabled MDBGEN in the DBGSCRext register. The execution address was put into the DBGBVR register and 0x1E7 was put into BCR0.
The desired preFetch Exception occurred.
However, when the debugger is plugged in, it stops right before executing the preFetch Exception in vectortable.
I do not know the reason.
When I unplug the debugger, it appears to be running well on preFetch Exception.
Second, when riding an Exception, the return address is a vector table. There is no address value anywhere in the stack to move to the BP-blocked address. When the IFAR register value is read from the Exception Handler, the preFetch execution address is captured in the vectorable.
shincm said:However, when the debugger is plugged in, it stops right before executing the preFetch Exception in vectortable.
My knowledge of Armv7-R debug is more than a little rusty, but I I think the problem is that you're effectively trying to use an external debugger to debug a self-hosted debugger.
Let's assume you're using a BKPT instruction to implement the breakpoint. When Halting debug-mode is NOT enabled, this instruction generates an exception (Prefetch abort) which can be handled by software - the self-hosted debugger. Once Halting debug-mode IS enabled, BKPT causes entry into Debug state. Connecting the external debugger will likely (depends on the debugger) have caused Halting debug-mode to be enabled. Again depending on the debugger, the debugger might not be able to tell the breakpoint that caused it to stop wasn't one it had set.
Thank you. your answerBut I think it's a slightly different issue.I think there might be something else other than MEBGEN.The External debugger's halting operation will not work if I do not use the BP debugger software on PC.This is because in the case of coretex-m, putting the key value in the dhcr register disables the halt operation.
M-profile isn't my area, so I can't comment on that part.
But since this in on a Cortex-R5F - I think we're saying the same (or similar) thing in different ways. From C1.2.1 in the Armv7-A/R Profile Architecture Reference Manual says:
A debugger programs the Debug Status and Control Register, DBGDSCR, to configure which debug-mode is used: Monitor debug-mode:In Monitor debug-mode, a debug event causes a debug exception to occur:• A debug exception that relates to instruction execution generates a Prefetch Abort exception.• A debug exception that relates to a data access generates a Data Abort exception.Chapter C4 Debug Exceptions describes these exceptions. Halting debug-modeIn Halting debug-mode, a debug event causes the processor to enter Debug state. In Debug state,the processor stops executing instructions from the location indicated by the program counter, butis instead controlled through the external debug interface, in particular using the InstructionTransfer Register, DBGITR. This enables an external agent, such as a debugger, to interrogateprocessor context, and control all subsequent instruction execution. Because the processor isstopped, it ignores the system and cannot service interrupts.Chapter C5 Debug State describes this state. A debug solution can use a mixture of the two methods, for example to support an OS or RTOS with both:• Running System Debug (RSD) using Monitor debug-mode.• Halting debug-mode support available as a fallback for system failure and boot time debug. The architecture supports the ability to switch between these two debug-modes.
A debugger programs the Debug Status and Control Register, DBGDSCR, to configure which debug-mode is used:
Monitor debug-mode:In Monitor debug-mode, a debug event causes a debug exception to occur:• A debug exception that relates to instruction execution generates a Prefetch Abort exception.• A debug exception that relates to a data access generates a Data Abort exception.Chapter C4 Debug Exceptions describes these exceptions.
Halting debug-modeIn Halting debug-mode, a debug event causes the processor to enter Debug state. In Debug state,the processor stops executing instructions from the location indicated by the program counter, butis instead controlled through the external debug interface, in particular using the InstructionTransfer Register, DBGITR. This enables an external agent, such as a debugger, to interrogateprocessor context, and control all subsequent instruction execution. Because the processor isstopped, it ignores the system and cannot service interrupts.Chapter C5 Debug State describes this state.
A debug solution can use a mixture of the two methods, for example to support an OS or RTOS with both:• Running System Debug (RSD) using Monitor debug-mode.• Halting debug-mode support available as a fallback for system failure and boot time debug.
The architecture supports the ability to switch between these two debug-modes.
The last part is important - you can switch between the modes. And when you connect the external debugger that's what I think is happening, it's switching from Monitor debug-mode to Halting debug-mode.
Thank you.
Your answer was helpful.I need to find a way to not change to halting debug-mode even when I connect the debugger.