Nucleo-U575ZI-Q download fails intermittently with OpenOCD

[Rob Meades]

I find that, every so often, flash download to my Nucleo-U575ZI-Q board from OpenOCD (driven by Zephyr west) fails.  The error reported is usually Error: [STM32U575ZITxQ.cpu] Could not find MEM-AP to control the core, though sometimes it doesn't seem to even get that far.  This happens on more than one board and from more than one PC.  The FW image I am loading is not a secure one. What might I do to stabilise the situation?

Here is a fail case:

Info : STLINK V3J12M3 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.289600
Info : Unable to match requested speed 500 kHz, using 200 kHz
Info : Unable to match requested speed 500 kHz, using 200 kHz
Info : clock speed 200 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x0be12477
Error: [STM32U575ZITxQ.cpu] Could not find MEM-AP to control the core
Warn : target STM32U575ZITxQ.cpu examination failed
Info : starting gdb server for STM32U575ZITxQ.cpu on 3333
Info : Listening on port 3333 for gdb connections
TargetName Type Endian TapName State 
-- ------------------ ---------- ------ ------------------ ------------
0* STM32U575ZITxQ.cpu cortex_m little STM32U575ZITxQ.cpu unknown
Info : Unable to match requested speed 480 kHz, using 200 kHz
Info : Unable to match requested speed 480 kHz, using 200 kHz
Error: [STM32U575ZITxQ.cpu] Could not find MEM-AP to control the core
Error: [STM32U575ZITxQ.cpu] Could not find MEM-AP to control the core
Error: [STM32U575ZITxQ.cpu] Debug AP not available, will not halt after reset!
Error: [STM32U575ZITxQ.cpu] Could not find MEM-AP to control the core
TARGET: STM32U575ZITxQ.cpu - Not examined

...or sometimes I just get this:

Info : STLINK V3J12M3 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.284042
Error: init mode failed (unable to connect to the target)

...while here is a success case:

Info : STLINK V3J12M3 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.282447
Info : Unable to match requested speed 500 kHz, using 200 kHz
Info : Unable to match requested speed 500 kHz, using 200 kHz
Info : clock speed 200 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x0be12477
Info : [STM32U575ZITxQ.cpu] Cortex-M33 r0p4 processor detected
Info : [STM32U575ZITxQ.cpu] target has 8 breakpoints, 4 watchpoints
Info : starting gdb server for STM32U575ZITxQ.cpu on 3333
Info : Listening on port 3333 for gdb connections
TargetName Type Endian TapName State 
-- ------------------ ---------- ------ ------------------ ------------
0* STM32U575ZITxQ.cpu cortex_m little STM32U575ZITxQ.cpu unknown
Info : Unable to match requested speed 480 kHz, using 200 kHz
Info : Unable to match requested speed 480 kHz, using 200 kHz
CPU in Non-Secure state
[STM32U575ZITxQ.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0xf9000000 pc: 0x0804d78c msp: 0x2002c2c0
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : device idcode = 0x20016482 (STM32U57/U58xx - Rev X : 0x2001)
Info : TZEN = 0 : TrustZone disabled by option bytes
Info : RDP level 0 (0xAA)
Info : flash size = 2048 KiB
Info : flash mode : dual-bank
Info : Padding image section 0 at 0x080ab4ac with 4 bytes (bank write end alignment)
Warn : Adding extra erase range, 0x080ab4b0 .. 0x080abfff
auto erase enabled
wrote 701616 bytes from file /home/ubxlib/workspace/ubxlib_PR-1149/_jenkins_work/32/build/zephyr/zephyr.hex in 5.656373s (121.133 KiB/s)
Info : Unable to match requested speed 480 kHz, using 200 kHz
Info : Unable to match requested speed 480 kHz, using 200 kHz
shutdown command invoked

[Jacob WOODRUFF]

Hi All,

This post has been escalated to the ST Online Support Team for additional assistance. We'll contact you directly.

Regards,
Jake

ST Support

[a14523]

Hello Rob,
is there any public solution to this issue? I observe the aformentioned behaviour (sporadically failing start of debug session with "Error: [stm32u5x.cpu] Could not find MEM-AP to control the core") on the exact same setup (Nucleo-U575ZI-Q with OpenOCD).
Many thanks.
Adam

[a14523]

Hello all,
I just wanted to share the fix, which solved the issue in my case (see above).
At the first run the debug session could be started and I downloaded a binary, where I applied an incorrect system clock setting. During debugging I let my code run, and after the execution reached the place, where the incorrect clock setting was set, I lost the connection to the mcu. This incorrect setting casued the mcu stuck in a strange state, where the communication with the STLINK V3 debugger was not possible at all, not even with the STM32CubeProgrammer. After many unsuccessful tries I took my J-Link Mini debugger, which was able to start and execute the debug session. So I could find the place, where the execution was lost, and I could fix the bug in my code. Once the corrected binary ran in my target, V3 and OpenOCD worked again.
Regards,
Adam

[Rob Meades]

@a14523: delving through my e-mail archives, I suspect my issue was not related to what you are seeing.  Here is the detail:

I narrowed-down the circumstances of the failure and no longer think it is connected with OpenOCD 'cos I can make the same thing happen with the STM32Cube Programmer. The pattern was this:

• Download our FW image to the NUCLEO-U575ZI-Q board.
• Everything works happily, the debugger remains connected, more FW may be downloaded, debugged, all is good, UNTIL...
• ...I power-cycled the board. Once that was done the STM32Cube Programmer would not connect ever again. Only manual intervention, connecting BOOT0 to VDD to enable boot from ROM, then connecting to the board under reset with the STM32Cube Programmer and performing a complete flash erase, would recover the situation.

Now, in our code, since we are using SWD for our main trace output, we configure SWD at boot to run at 2 MHz (i.e. U_CFG_HW_SWO_CLOCK_HZ set to 2000000, though note that the same thing happens at lower rates), code taken from  https://wiki.segger.com/J-Link_SWO_Viewer, as follows:

uint32_t stimulusRegs;
 
// Enable access to SWO registers
DEMCR |= (1 << 24);
ITM_LSR = 0xC5ACCE55;
 
// Initially disable ITM and stimulus port
// To make sure that nothing is transferred via SWO
// when changing the SWO prescaler etc.
stimulusRegs = ITM_ENA;
stimulusRegs &= ~(1 << 0); // Disable stimulus port 0
ITM_ENA = stimulusRegs;
ITM_TCR = 0; // Disable ITM
 
// Initialize SWO (prescaler, etc.)
TPIU_SPPR = 0x00000002; // Select NRZ mode
TPIU_ACPR = (SystemCoreClock / U_CFG_HW_SWO_CLOCK_HZ) - 1;
ITM_TPR = 0x00000000;
DWT_CTRL = 0x400003FE;
FFCR = 0x00000100;
 
// Enable ITM and stimulus port
ITM_TCR = 0x1000D; // Enable ITM
ITM_ENA = stimulusRegs | (1 << 0); // Enable stimulus port 0

This always worked fine for our STM32F4 boards (we've used it for years) but obviously not for the STM32U5 board; when I disabled use of this code, things worked across a power-cycle.

Our preference was to keep the code in place as it allowed us to set the SWD speed across MCU-driver resets (when no debugger will know to re-configure the rate); ST advised that the issues was with these three addresses, which are not present in the U575:

#define TPIU_ACPR (*(volatile uint32_t *) 0xE0040010)
#define TPIU_SPPR (*(volatile uint32_t *) 0xE00400F0)
#define FFCR (*(volatile uint32_t *) 0xE0040304)

And indeed, removing the accessing of those registers did remove the problem, however the write to the TPIU_ACPR register is the thing that sets the SWD speed, which is the whole point.  The advice from ST which followed was that we needed to enable access to the registers as follows:

DBGMCU->CR |= 0x000000e6; // DBG_STOP = 1, DBG_STANDBY = 1, TRACE_EN = 1, TRACE_MODE = 3

...then access to FFCR, TPIU_SPPR and TPIU_ACPR would work.  However, we had already decided just to remove the SWD speed-setting assembler by that point so never tried this ourselves.