Skip to main content
Senior
March 10, 2022
Solved

STM32WL55 dual core debug _ error 18 when debugging CM0+

Hello,

I have started to use stm32wl55 nucleo.

I try to debug a basic application.

I start by debugging CPU1 (CM4) than after booting CPU2 (CM0+) i run the debug for the second CPU.

But ST-LINK: Could not verify ST device!

error details :

Error in final launch sequence:

Failed to start GDB server

Failed to start GDB server

Error in initializing ST-LINK device.

Reason: (18) Could not verify ST device! Abort connection.

Any suggestion ?

Thank's.

This topic has been closed for replies.
mattias norlander
ST Employee
March 31, 2022

Hi,

Yes, unfortunately a regression bug has been confirmed with respect to debugging of STM32WL Cortex-M0+ core in STM32CubeIDE 1.9.0 vs previous versions. 

  • Short-term: The few number of users affected are advised to use STM32CubeIDE 1.8.0 which contains a matching feature set with respect to STM32WL development.
  • Long-term: The final fix will be delivered in the next STM32CubeIDE version.

Sorry for the inconvenience!

Kind regards, Mattias

16 replies

Senior
March 28, 2024

I have the same issue with the STM32WL55 (on the NUCLEO-WL55JC). I added two debug configurations as per the video. I can run each configuration individually just fine. But starting both simultaneously doesn't work, I also get the error "Target unknown error 32" when starting the 2nd configuration, for the M0 core. I am sure the M0 application is running though, it can access/modify global variables while I'm debuggin the M4. I also tried starting the ST-LINK_gdbserver.exe manually for the M0 core, but I get the same error:

 

C:\ST\STM32CubeIDE_1.14.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.1.200.202401191126\tools\bin> .\ST-LINK_gdbserver.exe -p 61237 -l 1 -d -t -s -cp C:\ST\STM32CubeIDE_1.14.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.1.200.202311302303\tools\bin -m 1 -g --halt


STMicroelectronics ST-LINK GDB server. Version 7.6.0
Copyright (c) 2024, STMicroelectronics. All rights reserved.

Starting server with the following options:
 Persistent Mode : Disabled
 Logging Level : 1
 Listen Port Number : 61237
 Status Refresh Delay : 15s
 Verbose Mode : Disabled
 SWD Debug : Enabled

ST-LINK device status: UNKNOWN
Waiting for debugger connection...
Shutting down...
Exit.

 

The option -t is definitely passed to the M4's gdbserver. STM32CubeIDE is version 1.15.0. Is there any kind of workaround, perhaps by starting the tools manually? Using the stlink-server? Installing just the old GDB-Server without downgrading the entire IDE?

Associate
June 1, 2024

Hey Guys,

I had the same issue. I just followed the steps in the readme of the dual core lorawan project I was working with. You need to set a break point after the function when you launch the CM4 debug:

HAL_PWREx_ReleaseCore(PWR_CORE_CPU2);

This halts the CM4 and powers up the CM0+ to be operational and running. You can then launch the CM0+ configuration and you will see that the debugger gets connected. You can then resume CM4 and continue with dual core debugging.

Specific steps from the readme:

@par How to debug ?
 - Open your preferred toolchain and select CM4 project
 - define the flag DEBUGGER_ENABLED to 1 in CM4\Core\Inc\sys_conf.h
 - define the flag LOW_POWER_DISABLE to 1 at least on one MCU (CM4 or CM0PUS)
 - compile and download
 - put a breakpoint in sys_app.c one line after HAL_PWREx_ReleaseCore(PWR_CORE_CPU2);
 - run CM4 (the above functions sets PWR_CR4_C2BOOT flag)
 - open a second instance of your preferred toolchain and select CM0PLUS project
 - to debug CM0PLUS as well, define the flag DEBUGGER_ENABLED to 1 in CM0PLUS\Core\Inc\sys_conf.h
 - define the flag LOW_POWER_DISABLE to 1 at least on one MCU (CM4 or CM0PUS)
 - compile and download using "Download active application"
 - once CM0PLUS code is downloaded reset (system reset) the CM4
 - run CM4 to the breakpoint again
 - attach to running target CM0PLUS
 (CM0PLUS is in a while loop waiting CM4 to give green light to go further)
 (this is done to prevent CM0PLUS to execute too much code before attaching)
 - on CM4 execute MBMUXIF_SetCpusSynchroFlag(1); this will allow CM0PLUS to exit the while loop

 

Debug configuration and additional info in here:
Getting started with projects based on dual-core STM32WL microcontrollers ​​in STM32CubeIDE - Application note