On 14/07/2023 19:31, Tommy Murphy wrote:
> The code reliably replicating the issue on STM32F767
Hi Tomas - that's very interesting and presumably something that Liviu
might try on his target? Can you clarify the rXpY version of your
target please? Thanks.
So far tested:
STM32F767 nucleo board - Cortex-M7 r1p0 - probably the same hw as the
first device Liviu spotted the problem at.
Atmel SAME70N21 custom board - Cortex-M7 r0p1 - identical issue
STM32F722 nucleo board - Cortex-M7 r1p1 - identical issue
STM32H7A3 custom board - Cortex-M7 r1p1 - identical issue
STM32H745 custom board - Cortex-M7 r1p1 - identical issue, no problems
on Cortex-M4 core
Unfortunately I don't have a Cortex-M7 r0p2 and r1p2 in my boards
collection.
r0p2 probably has the same issue like both older r0p1 and newer r1p0.
I'm more interested in testing the newest r1p2. Any tip to a device
containing Cortex-M7 r1p2 core?
Any owner of r1p2 device keen to run the test?
I remember I had feeling that Cortex-M7 stops in the debugger somewhat
too often.
But for debugging of the code loaded into flash I use exclusively FPB
based hw breakpoints,
not sw inserted BKPT instructions. So I added the following test:
while (1) {
SCB->ICSR |= SCB_ICSR_PENDSVSET_Msk;
__NOP();
// A FPB breakpoint placed in the following range triggers twice
similarly like BKPT
__NOP(); // The range starts here...
__NOP(); // :
__NOP(); // :
__NOP(); // :
__NOP(); // :
__NOP(); // :
__NOP(); // :
__NOP(); // ...the range ends here
__NOP(); } The issue induces a debug halt into the interrupt
service routine no matter if triggered by a BKPT instruction or the
signal from FPB unit. T
