Skip to main content
Senior
Mar 10, 2022 3:40 PM UTC
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 Technical Moderator
Mar 31, 2022 9:43 AM UTC

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

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question.

16 replies

Senior
Mar 28, 2024 10:01 AM UTC

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
Jun 1, 2024 4:31 PM UTC

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