Hi, my app (cortex m3) needs to set up a breakpoint directly from code, in order to jump to an interrupt when an instruction from a certain address is fetched. This WITHOUT using a debugger.
Any hint or tutorial? I think the only possible way is the patch block but it seems quite complicated.
Best regards
Franto
The Armv7-M architecture reference manual is here: https://developer.arm.com/documentation/ddi0403/latest/
See page C1-696
Do you have a debugger connected at the same time? Debug monitor and halt mode debug cannot be used at the same time.
regards,
Joseph
Hi Joseph, thanks for the manual. I see your point, C_DEBUGEN is set when there's a debug session, and this bit cannot be turned off from SW, only from the debugger. Unfortunately using the EWARM debugger for STM32 processors, there does not seem to be a way to run a debug session without halt mode so that I could still print to the terminal IO, see variables, etc even if I can't halt the processor. Do you think the only way to debug this kind of application will be to use printfs and no debugger at all? What I'm seeking is a way to programmatically disable halt mode, use the debug monitor for some routines, then re-enable halt mode and keep debugging with the debugger within EWARM. Any idea if this is possible?
Unformtunately I don't see any way to get this to work in Armv7-M. What is the aims you are trying to achieve?
Hi Joseph, I am trying to implement an instruction counter. Something like startCountingInstructions(); and int count = stopCountingInstructions(); I already wrote the code for it, but I cannot use it because I am connected to the STM32 with a debugger. I would like to use this instruction counter while also debugging the chip, instead of having to connect a serial terminal and print out 'count' without debugging.
Sorry for the delay.
Instead of using debug monitor, you could use a timer interrupt. For each step, set the timer interval to minimal to start off with, if the stacked PC is unchanged after return to the timer ISR, increase the timer interval by 1 to retry. Eventually, the "single stepping" of the instruction would suceed, and you can move to the next one, with the interval restart from minimun value.
Because the Cortex-M3/M4 has an interrupt entry latency of 12 cycle, and an interrupt exit latency possibly around 10 cycles (I can't remember the exact figure, could be 12 but I am not sure), I would choose the minimum interval as 20 cycle as starting point and increase it 1 cycle at a time.