Loading...
 

Zephyr project on STM32

   Zephyr Workbench, a VSCode extension to manage Zephyr on STM32.
It enables users to easily create, develop, and debug Zephyr applications.
Main features:
  • Install host dependencies.
  • Import toolchain and SDK.
  • Create, configure, build and manage apps.
  • Debug STM32.
You can directly download it from the VSCode marketplace
For more details, visit the Zephyr Workbench

System Workbench for STM32


Debugger stopped working after upgrade to version 2.0 and 2.1

After upgrading to 2.0, the debugger stopped working with my Nucleo-F411RE board and upgrading today to the new 2.1 did not solved the issue.
ST-Link works fine (I’m able to erase and program successfully the chip from right click Project menu->Target), but with Debug the procedure hangs without errors with these console messages:

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1800 kHz
adapter_nsrst_delay: 100
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v28 API v2 M v18 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.252174
Info : STM32F411RETx.cpu: hardware has 6 breakpoints, 4 watchpoints

The ST-Link LED blinks between green and red (meaning that communication is fine) but the chip is never reset and or halted, the debug tab with main.c is never open and on the right bottom of Eclipse I have “Launching TestPrg Debug (62%)” with the flowing green bar.

Has someone a solution, please?

Thanks and best regards

Hi,

You can activate the verbose mode for openocd by adding the option “-d” in your debug configuration: debugger tab -> “OpenOCD Options”. The verbose mode will help us to understand the issue.
But if you add this option, you may need to increase the console buffer size or simply turn off the limit. To do that,go to the preferences of the console (right click on the console -> preferences)

In my env (System workbench 2.1), a simple test case on a Nucleo-F411RE works.

Regards

Many thanks for the quick answer.
These are the last lines displayed before it hangs:

Debug: 588 2156 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_flash init
Debug: 589 2156 command.c:145 script_debug(): command - ocd_flash ocd_flash init
Debug: 591 2156 tcl.c:1097 handle_flash_init_command(): Initializing flash devices...
Debug: 592 2156 command.c:366 register_command_handler(): registering ‘ocd_flash’...
Debug: 593 2156 command.c:366 register_command_handler(): registering ‘ocd_flash’...
Debug: 594 2156 command.c:366 register_command_handler(): registering ‘ocd_flash’...
Debug: 595 2156 command.c:366 register_command_handler(): registering ‘ocd_flash’...
Debug: 596 2156 command.c:366 register_command_handler(): registering ‘ocd_flash’...
Debug: 597 2156 command.c:366 register_command_handler(): registering ‘ocd_flash’...
Debug: 598 2156 command.c:366 register_command_handler(): registering ‘ocd_flash’...
Debug: 599 2156 command.c:366 register_command_handler(): registering ‘ocd_flash’...
Debug: 600 2172 command.c:366 register_command_handler(): registering ‘ocd_flash’...
Debug: 601 2172 command.c:366 register_command_handler(): registering ‘ocd_flash’...
Debug: 602 2172 command.c:366 register_command_handler(): registering ‘ocd_flash’...
Debug: 603 2172 command.c:366 register_command_handler(): registering ‘ocd_flash’...
Debug: 604 2172 command.c:366 register_command_handler(): registering ‘ocd_flash’...
Debug: 605 2172 command.c:366 register_command_handler(): registering ‘ocd_flash’...
Debug: 606 2172 command.c:366 register_command_handler(): registering ‘ocd_flash’...
Debug: 607 2172 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_mflash init
Debug: 608 2172 command.c:145 script_debug(): command - ocd_mflash ocd_mflash init
Debug: 610 2172 mflash.c:1379 handle_mflash_init_command(): Initializing mflash devices...
Debug: 611 2172 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_nand init
Debug: 612 2172 command.c:145 script_debug(): command - ocd_nand ocd_nand init
Debug: 614 2172 tcl.c:497 handle_nand_init_command(): Initializing NAND devices...
Debug: 615 2172 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_pld init
Debug: 616 2172 command.c:145 script_debug(): command - ocd_pld ocd_pld init
Debug: 618 2172 pld.c:207 handle_pld_init_command(): Initializing PLDs...


Thanks and best regards

Hi Microdevice,

Is it possible to share all the trace displayed please?
The last lines seems to be ok.

Regards

Hi Vionf,
I attached a text file with the entire trace.
I forgot to tell you that I’m using the 32 bit version of SW4STM32 and the OS is Windows XP
Thanks and best regards


I’m in a “cul the sac” :-(
I need to go further, so I try to uninstall the version 2.x and install again the last version 1.x that I was using.
Best regards


Hi,

Is this debug hang problem with Win-XP being addressed, or should version 1.8 be considered the last version that works with Win-XP ?


 

Newest Forum Posts

  1. SPI on Nucleo_STMH533RE by royjamil, 2025-05-04 20:13
  2. SPI on Nucleo_STMH533RE by higginsa1, 2025-03-25 07:37
  3. SPI on Nucleo_STMH533RE by royjamil, 2025-03-23 11:31
  4. SPI on Nucleo_STMH533RE by higginsa1, 2025-03-23 09:33
  5. Configuring DMA for ADC in SW? by sam.hodgson, 2025-03-04 12:58
  6. Build a project in "release" mode by info@creosrl.it, 2025-02-20 18:12
  7. Build a project in "release" mode by info@creosrl.it, 2025-02-20 17:05
  8. Build a project in "release" mode by tang, 2025-02-20 10:36
  9. Build a project in "release" mode by info@creosrl.it, 2025-02-19 17:35
  10. Fail to debug in Win 11 C/C++ by mortenlund, 2024-12-26 20:27

Last-Modified Blogs