Debugging the Lora-STM32WL-devkit: Open On-Chip Debugger failed

[Volker]

Connected Lora-STM32WL-devkit (just purchased) to the PC via USB (Com port 6)
Compiled BB-STM32WLE-WAN using STM32Cube version 1.17.0 in debug mode successfully.
Replaced the enviroment varibale for the path of OpenOCD by
C:\ST\STM32CubeIDE_1.17.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.openocd.win32_2.4.100.202501161620\tools\bin\openocd
Starting debug, get the message:
Open On-Chip Debugger 0.12.0+dev-00608-gd8ed48fef (2025-02-06-11:17) [https://github.com/STMicroelectronics/OpenOCD]
stm32wlx_cti_prepare_restart_one
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Error: open failed

I have already read some older threads by 2023 and older referring to older versions of STM32Cube.

Any suggestions?

Regards, Volker

[Volker]

In the meantime I called openOCD directly from the command line:
cd C:\ST\STM32CubeIDE_1.17.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831\resources\openocd\st_scripts

C:\ST\STM32CubeIDE_1.17.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.openocd.win32_2.4.100.202501161620\tools\bin\openocd.exe -f interface/cmsis-dap.cfg -c "cmsis-dap vid_pid 0x15ba 0x0044" -c "transport select swd" -c "adapter speed 4000" -f "target/stm32wlx.cfg" -c "program D:\\PrgWrk\\STM32\\workspace_1.17.0\\BB-STM32WLE-WAN\\Debug\\BB-STM32WLE-WAN.elf"

Response:
Open On-Chip Debugger 0.12.0+dev-00608-gd8ed48fef (2025-02-06-11:17) [https://github.com/STMicroelectronics/OpenOCD]
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
swd
adapter speed: 4000 kHz
stm32wlx_cti_prepare_restart_one
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: FW Version = 1.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 4000 kHz
Info : SWD DPIDR 0x6ba02477
Info : [stm32wlx.cm4] Cortex-M4 r0p1 processor detected
Info : [stm32wlx.cm4] target has 6 breakpoints, 4 watchpoints
Info : [stm32wlx.cm4] Examination succeed
Info : starting gdb server for stm32wlx.cm4 on 3333
Info : Listening on port 3333 for gdb connections
[stm32wlx.cm4] halted due to breakpoint, current mode: Thread
xPSR: 0x01000000 pc: 0x08003094 msp: 0x20008000
** Programming Started **
Info : device idcode = 0x10016497 (STM32WLE/WL5x - Rev 'unknown' : 0x1001)
Info : RDP level 0 (0xAA)
Info : flash size = 256 KiB
Info : flash mode : single-bank
Info : Padding image section 1 at 0x0801f8cc with 4 bytes (bank write end alignment)
Warn : Adding extra erase range, 0x0801f8d0 .. 0x0801ffff
Info : SWD DPIDR 0x6ba02477
Error: Failed to write memory at 0x20009488
Error: block write failed
Error: error writing to flash at address 0x08000000 at offset 0x00000000
embedded:startup.tcl:1689: Error: ** Programming Failed **
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 1754
at file "embedded:startup.tcl", line 1689
PS C:\ST\STM32CubeIDE_1.17.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831\resources\openocd\st_scripts>

What's wrong now?

[Volker]

Started a GDB server between OpenOCD and the board (GDB server is useful for software tools that support such connection):

C:\ST\STM32CubeIDE_1.17.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.openocd.win32_2.4.100.202501161620\tools\bin\openocd -f interface/cmsis-dap.cfg -c 'sleep 10' -c "cmsis-dap vid_pid 0x15ba 0x0044" -c "transport select swd" -c "adapter speed 4000" -f "target/stm32wlx.cfg"
Open On-Chip Debugger 0.12.0+dev-00608-gd8ed48fef (2025-02-06-11:17) [https://github.com/STMicroelectronics/OpenOCD]
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
swd
adapter speed: 4000 kHz
stm32wlx_cti_prepare_restart_one
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: FW Version = 1.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 4000 kHz
Info : SWD DPIDR 0x6ba02477
Info : [stm32wlx.cm4] Cortex-M4 r0p1 processor detected
Info : [stm32wlx.cm4] target has 6 breakpoints, 4 watchpoints
Info : [stm32wlx.cm4] Examination succeed
Info : starting gdb server for stm32wlx.cm4 on 3333
Info : Listening on port 3333 for gdb connections

<<< Started Debugging from STM32Cube IDE>>>

Info : accepting 'gdb' connection on tcp/3333
Info : device idcode = 0x10016497 (STM32WLE/WL5x - Rev 'unknown' : 0x1001)
Info : RDP level 0 (0xAA)
Info : flash size = 256 KiB
Info : flash mode : single-bank
undefined debug reason 8 (UNDEFINED) - target needs reset
[stm32wlx.cm4] halted due to breakpoint, current mode: Thread
xPSR: 0x01000000 pc: 0x08003094 msp: 0x20008000
Info : Padding image section 0 at 0x08000138 with 8 bytes
Info : Padding image section 1 at 0x0801f8cc with 4 bytes (bank write end alignment)
Info : SWD DPIDR 0x6ba02477
Error: Failed to write memory at 0x20009480
Error: block write failed
Error: error writing to flash at address 0x08000000 at offset 0x00000000
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (6924 ms). Workaround: increase "set remotetimeout" in GDB
[stm32wlx.cm4] halted due to breakpoint, current mode: Thread
xPSR: 0x01000000 pc: 0x08003094 msp: 0x20008000
shutdown command invoked
Info : dropped 'gdb' connection

Remark: Tried several USB cables in order to exclude cable problems.

I am close to giving up. Software as well hardware seem to be unreliable.

[LubOlimex]

Looking at the last log it appears the connection between the board and OpenOCD is fine. The issue appears somewhere from STM32CubeIDE settings.

Looking at the previous log it appears the issue is maybe in the OpenOCD version.

My advice is to try with OpenOCD version 0.11.x (previous to 0.12.x).

[Volker]

Thank you very much for your answer.

I installed version STM32Cube 1.10.0. which includes version OpenOCD version 0.11.x parallel to STM32Cube 1.17.0.

I experience the same problem compared to the last log. Looks as if we have to work with the slow upload.

Is it possible to use the ST-Link V2?
If yes, how looks the debug configuration?

[LubOlimex]

Yes, it should be much better using external SWD programmer like STLINK/V2 compared to using the on-board USB debugging method. Also STLINK/V2 is well-supported in STM32Cube.

You connect the external SWD programmer to pins named C, D, G of CON1 connector. C is clock (SWCLK2), D is data (SWDIO2), G is ground.

For the software you might need to install the STM32WL package (since this is the main chip):

https://www.st.com/en/embedded-software/stm32cubewl.html

The information above was wrong, you can't program the top board via the C, D, G pins of bottom board. Explained here:

https://www.olimex.com/forum/index.php?topic=9750.msg45777#msg45777

[Volker]

You connect the external SWD programmer to pins named C, D, G of CON1 connector. C is clock (SWCLK2), D is data (SWDIO2), G is ground.

We have tried this already. Target is not found.

Consists the documentation of the Lora-STM32-DevKit mainly out of several readme.md's?
The Link for LoRa-STM32WL-DevKit user manual on page https://www.olimex.com/Products/IoT/LoRa/LoRa-STM32WL-DevKit/open-source-hardware is deactivated. Is there no manual?
ANother user has already aksed it. But no answer.

Do we have to upload cmsis-dap first? Which config?
Do we have to install several other compilers in order to compile utilities like dfu-util and the right version of OpenOCD?

What is the base configuration of BB-STM32WLE-WAN?
LoRaWAN version LoRaWAN Specification 1.0.3 or another?
Regional Parameters version RP001 Regional Parameters 1.0.3 revision A?

In general:
We have put a lot of time into this project and no real progress.
Debugging is unreliable. Documentation confusing. No straight forward way to a working basic version.

We have already successfully worked with the board ELV-BM-TRX1 by ELV Elektronik which offers full documentation.

Seems to be time to stop working with Lora-STM32-DevKit and use the ELV-BM-TRX1 only. Sorry.


 

[LubOlimex]

Sorry for the experience. It is part of the engineering experience to evaluate options and chose what is best to achieve your goals.

We have tried this already. Target is not found.

We actually program each LoRa-STM32WL-DevKit via the SWD interface using STLINK/V2 after manufacturing. Each board is programmed via the SWD and tested. Edit: while this is true, it is only the chip of the bottom board STM32L052K8U3 that gets directly programmed, and it programs the top board. Also we use OpenOCD in the production tests, so we never met the problems with STM32Cube.

Either your hardware connections are improper or you haven't power the board from the USB.

My bad. Hardware design doesn't allow programming the top board via external programmer applied to the bottom board. Here: https://www.olimex.com/forum/index.php?topic=9750.msg45777#msg45777

Do we have to upload cmsis-dap first? Which config?
Do we have to install several other compilers in order to compile utilities like dfu-util and the right version of OpenOCD?

If you use a SWD programmer you don't have to use any CMSIS and stuff (this is only if you use the on-board debugger via the USB). You just select the programmer (in your case STLINK/V2) from the settings of STM32Cube, maybe select the SWD interface and you select proper target in the menu (STM32WL). If you don't see the target you need to install the support package for STM32WL. That's it.

https://www.olimex.com/forum/index.php?topic=9750.msg45777#msg45777

What is the base configuration of BB-STM32WLE-WAN?
LoRaWAN version LoRaWAN Specification 1.0.3 or another?
Regional Parameters version RP001 Regional Parameters 1.0.3 revision A?

Depends on the software application. Yes, 1.0.3 for both is possible. Check here:

https://www.st.com/resource/en/application_note/an5406-how-to-build-a-lora-application-with-stm32cubewl-stmicroelectronics.pdf

[Volker]

Sorry for the experience. It is part of the engineering experience to evaluate options and chose what is best to achieve your goals.

Well, you are right. Anyway, it is a kit. It would be helpful to have a detailed doc of a basic setup. As soon as the basic setup starts to work the user can begin to modify the kit for his goals.

In the meantime we checked if the ST-Link/V2 is still working with the module by ELV. It does. I should mention that the ELV module requires some more signals of the ST-Link/V2, not only Clk and Data.

Hardware:
Base board: Rev.D, (c) 2022
Small board: BB-STM32WL, Revi B.
Prozessor module: BB-STM32WL, ISM: 868 MHz, PA +J4 dBm
ST-Link/V2 is labeled with "B 2024 22"

Connections:
ST link V2, Pin 9 (JTAG TCK, SW CLK) --- Pin 8  (C) of CON1 (HN1x10) of  LoRa-STM32WL-DevKit
ST link V2, Pin 7 (JTAG TMS, SW IO)  --- Pin 7  (D) of CON1 (HN1x10) of  LoRa-STM32WL-DevKit
ST link V2, Pin 20 (GND)            --- Pin 10 (G) of CON1 (HN1x10) of  LoRa-STM32WL-DevKit

DevKit is powered via USB. The serial port outputs some sensor values periodically:
<23:23:55> ========= AHT20 =========
<23:23:55> MAG IIS2MDC OK
<23:24:05> AHT20 data: Pressure: 0hPa, Temperature: 29.6°C,
Humidity: 29%
<23:24:05> X: 65344, Y: 118, Z: 64990, light = 54%, vbat = 2
928mV
<23:24:05> Respond: <-2>


1. Does it matter which item is powered first? ST-Link/V2 or devkit?
2. Has Reset button or Button1 to be pressed during power-up?

3. BB-STM32WLE-WAN Debug.cfg contains: set CONNECT_UNDER_RESET 1
The reset pin is not connected to the ST-Link/V2. How can the devkit be reset other than by pressing the reset button?

4. Debugger settings
Autostart local GBD server, port 61234
Debug probe: ST_LINK (ST_LINK GBD SERVER)
Interface : SWD
ST-Link S/N: found by scan
Frequency: Autostart
Access port: 0-Cortex-M4
Reset behaviour: Connect under reset
SWV: disabled
Verify after download: enabled
Enable live expressions: disabled
log to file: disabled
Shared ST-Link: disabled
Max halt timeout(s): no

Message:
STMicroelectronics ST-LINK GDB server. Version 7.9.0
Copyright (c) 2024, STMicroelectronics. All rights reserved.
Starting server with the following options:
        Persistent Mode            : Disabled
        Logging Level              : 1
        Listen Port Number        : 61234
        Status Refresh Delay      : 15s
        Verbose Mode              : Disabled
        SWD Debug                  : Enabled
        InitWhile                  : Enabled

Target no device found

Error in initializing ST-LINK device.
Reason: No device found on target.
###End of Message###

5. When we set
Debug probe: ST_LINK (ST_LINK GBD SERVER)
we get the message:
Open On-Chip Debugger 0.12.0+dev-00600-g090b431b1 (2024-09-13-19:14) [https://github.com/STMicroelectronics/OpenOCD]
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
stm32wlx_cti_prepare_restart_one
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : STLINK V2J45S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 0.561936
Error: target voltage may be too low for reliable debugging
Error: init mode failed (unable to connect to the target)

Does the low voltage message mean anything?

The supply voltage between pin 1 and 2 of UEXT1 is measured to 2.87 volts.

[LubOlimex]

Alright, I figured it out. I was wrong before and didn't check thoroughly, sorry for this.

So it turns out that you can't program the top board (aka BB-STM32WL-ANT) via the pins of the bottom board using external programmer (STLINK/V2 in this case). This is due to the hardware design. The "C D G" pins are suitable only for programming the main chip of the bottom board STM32L052K8U3.

The SWDIO/SWDCLK pins of the top board (BB-STM32WL-ANT) are not directly routed to any header of the bottom board. They go straight to the STM32L052K8U3.

This means if you wish to use external programmer you would need to remove BB-STM32WL-ANT from the bottom board and use wires to connect to it directly, check the schematic:

https://www.olimex.com/Products/IoT/LoRa/BB-STM32WL/resources/BB-STM32WL_RevC.pdf

Use CON2 for debugging SWDIO SWCLK are pins 1 and 2 and then power from pin 7 with 3.3V and pin 8 GND.

Alternatively, use the USB programmer as explained here:

https://www.olimex.com/Products/IoT/LoRa/LoRa-STM32WL-DevKit/resources/USB-programming-STM32WL.txt

Pay attention to the STM32CubeIDE notice - it doesn't support DAP-CMSIS which means you need to build the code then upload the resulting binary via OpenOCD.

I will edit my previous posts.

I've added a notice to our hardware designers to explore ways to allow programming of top board via the bottom board using external programmer for future hardware revisions.

[Volker]

if you wish to use external programmer

We wish to use a reliable programmer and source level debugger, no matter if internal or external.
In addition it makes no sense for us to operate the processor without the base board.

We have more or less successfully the devkit programmed and debugged using the internal debugger as reported on this thread, see
https://www.olimex.com/forum/index.php?topic=9750.msg45722#msg45722
However, the upload fails in 3 of 4 cases. And when it does not fail, the upload takes several minutes as the flash programmer does not work for whatever reason.

Can Olimex provide a reliable configuration for the software and internal debugger for this kit as a starting point for their customers? It doesn't help to hear that it did once work at Olimex.
(As reported earlier going back to version 1.10.0 of CubeSTM32 did not help.)

[LubOlimex]

>As reported earlier going back to version 1.10.0 of CubeSTM32 did not help

Going back to older version of CubeSTM32 is required if you wish to build the Olimex demo project without issues, HOWEVER programming and debugging will NOT work via STM32CubeIDE directly since it doesn't support CMSIS. Check these threads of complains:

https://community.st.com/t5/stm32cubeide-mcus/cmsis-dap-debugger-in-stm32cubeide/td-p/765900

https://community.st.com/t5/stm32cubeide-mcus/cannot-debug-with-cmsis-dap-openocd-cubeide-in-win10/td-p/221224

As I mention in the text document:

"Some others (like STM32CubeIDE) do not and require first building the binary and then uploading manually."

This basically means you can use STM32CubeIDE to build the binary. But then you need to download it to the board via OpenOCD and you CAN NOT configure STM32CubeIDE to use OpenOCD, you have to download stand-alone OpenOCD, ignore STM32CubeIDE and use the stand-alone OpenOCD and the commands described in this document:

https://www.olimex.com/Products/IoT/LoRa/LoRa-STM32WL-DevKit/resources/USB-programming-STM32WL.txt

Debugging without the graphical interface would be a pain.

The alternative is using software that supports CMSIS programming like Keil uVision or IAR EW for ARM.

I will do some tests and a video about the first complaint about the unreliability. Have to check myself first.

[Volker]

This basically means you can use STM32CubeIDE to build the binary. But then you need to download it to the board via OpenOCD and you CAN NOT configure STM32CubeIDE to use OpenOCD, you have to download stand-alone OpenOCD, ignore STM32CubeIDE and use the stand-alone OpenOCD and the commands described in this document:

We are am two steps further. Seems as if ST did improve the support for debuggers from version 1.10 to 1.17:

1. We are able to launch the internal debugger with UI in STM32CubeIDE.
We made a screenshot as a proof.-) Of course we did also document the configuration. However, we do not know how to upload screenshots here.
Please see them here: https://community.st.com/t5/stm32cubeide-mcus/cannot-debug-with-cmsis-dap-openocd-cubeide-in-win10/td-p/221224

We launch openocd of the package STM32CubeIDE version 1.17 without uploading the program by the following commands in power shell:
cd C:\ST\STM32CubeIDE_1.17.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831\resources\openocd\st_scripts

C:\ST\STM32CubeIDE_1.17.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.openocd.win32_2.4.100.202501161620\tools\bin\openocd.exe -f interface/cmsis-dap.cfg -c "cmsis-dap vid_pid 0x15ba 0x0044" -c "transport select swd" -c "adapter speed 2000" -f "target/stm32wlx.cfg"

Response is:
Open On-Chip Debugger 0.12.0+dev-00608-gd8ed48fef (2025-02-06-11:17) [https://github.com/STMicroelectronics/OpenOCD]
Licensed under GNU GPL v2
For bug reports, read        http://openocd.org/doc/doxygen/bugs.html
swd
adapter speed: 2000 kHz
stm32wlx_cti_prepare_restart_one
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: FW Version = 1.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 4000 kHz
Info : SWD DPIDR 0x6ba02477
Info : [stm32wlx.cm4] Cortex-M4 r0p1 processor detected
Info : [stm32wlx.cm4] target has 6 breakpoints, 4 watchpoints
Info : [stm32wlx.cm4] Examination succeed
Info : starting gdb server for stm32wlx.cm4 on 3333
Info : Listening on port 3333 for gdb connections
### End of response ###

Then we launch the debugger from the STM32CubeIDE.
Response in power shell:
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: FW Version = 1.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 4000 kHz
Info : SWD DPIDR 0x6ba02477
Info : [stm32wlx.cm4] Cortex-M4 r0p1 processor detected
Info : [stm32wlx.cm4] target has 6 breakpoints, 4 watchpoints
Info : [stm32wlx.cm4] Examination succeed
Info : starting gdb server for stm32wlx.cm4 on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Info : device idcode = 0x10016497 (STM32WLE/WL5x - Rev 'unknown' : 0x1001)
Info : RDP level 0 (0xAA)
Info : flash size = 256 KiB
Info : flash mode : single-bank
undefined debug reason 8 (UNDEFINED) - target needs reset
[stm32wlx.cm4] halted due to breakpoint, current mode: Thread
xPSR: 0x01000000 pc: 0x08003094 msp: 0x20008000
Info : Padding image section 0 at 0x08000138 with 8 bytes
Info : Padding image section 1 at 0x0801f8cc with 4 bytes (bank write end alignment)
Info : SWD DPIDR 0x6ba02477
Error: Failed to read memory at 0x20009000
Error: allocating working area failed
Warn : falling back to programming without a flash loader (slower)
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (70932 ms). Workaround: increase "set remotetimeout" in GDB
[stm32wlx.cm4] halted due to breakpoint, current mode: Thread
xPSR: 0x01000000 pc: 0x08003094 msp: 0x20008000
### End of response ###

Remark: It might also be possible to launch openocd.exe from the STM32CubeIDE version 1.17.


2. There are a few contradictory settings in BB-STM32WLE-WAN.ioc of package LoRa-STM32WL-DevKIT-main.zip
Open BB-STM32WLE-WAN.ioc by double clicking in STM32CubeIDE. Look for the yellow exclamation marks.
Perhaps these settings obstruct flash programming. We have not checked it up to now. Would be a nice task for the engineers at Olimex.-)