Hi,
I'm trying to work with the STM32N6. I have a NUCLEO-N657X0-Q board.
When I use an external debugger via CN1 everything is fine, however I am experiencing a lot of trouble with the ST-Link.
It seems like there is a small (0.01%) chance that attempting to access memory will cause the device to lock up.
An example of the sort of command that gets sent to the ST-Link is: `[0xf2, 0x07, 0xfc, 0xff, 0x00, 0x34, 0xcc, 0x35, 0x01]`. That is, a simple command to the ST-Link to read or write memory.
I am doing this as part of an attempt to implement support for the STM32N6 for probe-rs, however the problem seems to occur even when using ST tools. For example, the following has a good chance of locking up:
./STM32_Programmer_CLI \
-c port=swd \
-r32 0x34000000 32768 \
-r32 0x34000000 32768 \
-r32 0x34000000 32768 \
-r32 0x34000000 32768 \
-r32 0x34000000 32768 \
-r32 0x34000000 32768 \
-r32 0x34000000 32768 \
-r32 0x34000000 32768 \
-r32 0x34000000 32768
Once the ST-Link has locked up, the only way to get it back is to unplug it and plug it in again. Any attempt to access the ST-Link USB endpoint will be met with silence.
In the example I've attempted to read main memory, however I see similar lockups when attempting to read ROM, or even when attempting to read register values repeatedly such as (to pick a random peripheral) 0x56028048, or even trying to read something from the ARM CoreSight block such as 0xE000ED14.
I am running ST-Link firmware V3J16M6 on the integrated debugger. This seems like it's a bug in the ST-Link, because running the link at a lower frequency reduces the failures. For example, they seem to go away entirely at around 100 kHz.
