2022-03-10 07:40 AM
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.
Solved! Go to Solution.
2022-12-08 12:44 AM
Hello,
I am experiencing the same issue. I have updated to 1.11.0 hoping this would solve the problem but the same happens. There is no 1.8.0 on my system, before 1.9.0 there is 1.7.0.
Any suggestions?
Gr.RFM
2023-02-28 12:58 AM
Hi
I have upgraded stm32cube to 1.11.2 now. I'm experiencing the same issue too.
Would you like to tell me when we will get this fix ?
2023-08-25 01:16 PM
I have the same issue on the STM32H747I-Eval board. Does not validate the CM4 core. I'd also like to know when this is being resolved.
2023-09-05 09:31 PM
We are many releases past 1.9.0. As of today, 1.13, so where is the fix for this issue?
2023-12-23 10:13 AM
I am using STM32H745 and I am facing this issue and I have searched for any one who has a solution but I can't find any one.
I am using cube ide 1.14 and have the same issue
ANy one can help?
2024-03-28 03:01 AM - edited 2024-03-28 03:01 AM
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?
2024-06-01 09:31 AM
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