Liviu, Antonio,
On 11/07/2023 07:22, Liviu Ionescu wrote:
On 11 Jul 2023, at 00:50, Antonio Borneo <borneo.anto...@gmail.com> wrote:
From what you say, it's not a matter of adapter (CMSIS-DAP and STLINK
give the same issue). It's not HLA vs Cortex-M.
That's correct
But you only get it on Cortex-M7, correct?
I can only confirm that none of the runs on a Raspberry Pico exhibited this
behaviour, I don't have configurations for other boards. but I plan to add one
for a STM32F411 BlackPill board...
But the issue is very time sensitive, simply adding a printf("\n") at the
beginning of the test and the problem no longer occurs.
Or, when running OpenOCD on the slower Raspberry Pi4, the result is different,
the debug binary hangs, and the release one passes.
So, the absence of the behaviour on one particular board, with a particular
application running on a host with a particular speed does not mean that the
problem does not exist, but that the critical timing did not occur. which makes
debugging this much more difficult :-(
Not to mention that with the J-Link and the SEGGER software, it did not occur.
Are you able to find what is the return PC address of the SysTick
exception/interrupt handler when it halts?
Just to know if it points to a BKPT
I would be very surprised if it's a bug in Cortex-M7, about an
exception occuring during a BKPT, but currently I have no other
suggestions.
I'll try to find a way to confirm this.
It is very likely that the exception occurs during a BKPT.
Couldn't it be related to the MASKINTS erratum of Cortex-M7 r0p1
or to its workarounds integrated to src/target/cortex_m.c?
Look for warning
"Silicon bug: single stepping may enter pending exception handler!"
Tom
