> On 11 Jul 2023, at 00:50, Antonio Borneo <borneo.anto...@gmail.com> wrote:
>
> Indeed, the behavior is weird. And as far as I know, this is the first
> time it is reported.
>
> Note: you have instrumented mem_ap_read_u32() with a LOG_INFO(), but
> the printed content of "value" is not updated yet.
> In fact mem_ap_read_u32() queues the read, but you are printing the
> uninitialized value, before the queue is executed.
Oops! I did not pay attention to these details :-(
Is there any easy way to display the value after the queue is executed?
> Your last dump shows that OpenOCD sends the "resume" command and then,
> less than 100 ms after, poll finds the CPU halted.
> And it's halted in the systick handler, where there is no BKPT
Ok, that was my understanding too.
> 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
> And it should not be a HW breakpoint
Not one that I'm aware of. since the program does not run via a debugger, and
the OpenOCD input ports are disabled, there is no way I can manually set a HW
breakpoint.
I don't know what the tcl scripts do, but I don't think they set any HW
breakpoint.
Also my test code does not explicitly set any, but I cannot guarantee for the
CubeMX initialisation code.
Do you know how to check if there was a HW breakpoint set? I guess there are
some registers in the debug logic which store these addresses. can we dump
these registers?
> 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.
> What happens if you type "resume" after this unexpected halt? Does it
> re-halt immediately or it continues running at least for a while?
With my current configuration i can't type resume since the input ports are
disabled.
But if I run the same binary via GDB in Eclipse, the execution resumes and the
test completes.
As I mentioned before, I see two issues, one that the execution halts, and one
that the execution does not resume.
In my opinion, when OpenOCD runs in a standalone semihosting mode (i.e. not via
a debugger), even if it encounters a breakpoint, it should automatically resume.
Perhaps we will not be able to prevent the F7 to trigger the breakpoint, but I
guess we could add the logic to resume it.
Liviu
