Upload failing for nucleo_f439zi with error in openocd

Firstly, thanks for an excellent framework. I am facing an issue uploading for mbed STM32F439ZIT6 using platformIO. I have tried to read various sources in order to better understand what’s going on and checked similar topics here, but the error returned from openocd doesn’t seem very clear as to what’s going wrong. I am very accustomed to embedded development with AVR, ESP, SAMD and Arduino, but not with ST32 boards, it is possible (and likely) that I’ve missed a step, and I apologise in advance if thats the case!

The platformio project I’m trying to build is an open source library that uploads fine for the MKR1300 and ATmega2560 targets, I can run the examples on either of the other two targets. You can see the full project setup on Github: GitHub - davetcc/IoAbstraction: Rotary encoders, fully debounced switches, EEPROM support on Arduino and mbed - direct and over I2C

Output of Device list (taken on Windows but similar report on MacOS):

>pio device list
COM8
----
Hardware ID: USB VID:PID=0483:374B SER=7 LOCATION=1-8:x.2
Description: STMicroelectronics STLink Virtual COM Port (COM8)

Two setups that I’ve tried this on:

Windows 10 with PlatformIO, version 4.3.3, cmd shell
IDE: Clion 2020.1 (mingw chain) (but this fails even from CLI)
CPU Ryzen 1700X, 32GB RAM, 500G M2 SSD.

MacOS Catalina with Platform IO version 4.3.3, zsh shell
IDE Clion 2020.1 (Fails even from CLI)
MacBook PRO 15" / 16GB RAM / 500G SSD.

Snippet of the error message taken from below log

Error: init mode failed (unable to connect to the target)
in procedure 'program'
** OpenOCD init failed **

Snippet of platformio.ini (see link at top of post for full project):

[env:STM439]
platform = ststm32
board = nucleo_f439zi
framework = mbed
;upload_port = /dev/cu.usbmodem14103
upload_port = COM8
;monitor_speed = 115200
build_flags = -D_NO_EEPROM_CLASS_=1, -DPIO_FRAMEWORK_MBED_RTOS_PRESENT

Command executed on both MacOS (zsh) and Windows 10 (cmd):

pio run -t upload -e STM439 -v

Full log contents:

Processing STM439 (platform: ststm32; board: nucleo_f439zi; framework: mbed; upload_port: COM8; build_flags: -D_NO_EEPROM_CLASS_=1, -DPIO_FRAMEWORK_MBED_RTOS_PRESENT)
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

CONFIGURATION: [link removed]/nucleo_f439zi.html
PLATFORM: ST STM32 6.1.0 > ST Nucleo F439ZI
HARDWARE: STM32F439ZIT6 180MHz, 256KB RAM, 2MB Flash
DEBUG: Current (stlink) On-board (stlink) External (blackmagic, jlink)
PACKAGES:
 - framework-mbed 6.51401.200402 (5.14.1)
 - tool-dfuutil 1.9.200310
 - tool-openocd 2.1000.190707 (10.0)
 - tool-stm32duino 1.0.2
 - toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
Collecting mbed sources...
LDF: Library Dependency Finder ->...
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 10 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <src> (C:\Users\dave\Documents\Arduino\libraries\IoAbstraction\src)
Building in release mode
MethodWrapper(["checkprogsize"], [".pio\build\STM439\firmware.elf"])
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=         ]   9.8% (used 25800 bytes from 262144 bytes)
Flash: [          ]   3.1% (used 64664 bytes from 2097152 bytes)
.pio\build\STM439\firmware.elf  :

section              size        addr

.text               61720   134217728

.ARM.exidx              8   134279448

.crash_data_ram       256   536871344

.data                2936   536871600

.bss                22864   536874536

.heap              169096   536897400

.ARM.attributes        46           0

.comment              126           0

.debug_info        951446           0

.debug_abbrev       99175           0

.debug_loc         161827           0

.debug_aranges      13448           0

.debug_ranges       20752           0

.debug_line        162102           0

.debug_str         171991           0

.debug_frame        41916           0

.stabstr              118           0

Total             1879827
<lambda>(["upload"], [".pio\build\STM439\firmware.elf"])
AVAILABLE: blackmagic, jlink, mbed, stlink
CURRENT: upload_protocol = stlink
openocd -d2 -s C:\Users\dave\.platformio\packages\tool-openocd/scripts -f board/st_nucleo_f4.cfg -c "program {.pio\build\STM439\firmware.elf}  verify reset; shutdown;"
xPack OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-11:28)
Licensed under GNU GPL v2
For bug reports, read
        [link removed]
debug_level: 2

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Info : clock speed 2000 kHz
Info : STLINK V2J36M26 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.235194
Error: init mode failed (unable to connect to the target)
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked

*** [upload] Error 1
===================================================================================================== [FAILED] Took 56.04 seconds =====================================================================================================

Environment    Status    Duration
-------------  --------  ------------
ATmega2560     IGNORED
Mkr1300        IGNORED
STM439         FAILED    00:00:56.036
================================================================================================ 1 failed, 0 succeeded in 00:00:56.036 ================================================================================================

Lastly, to remove any doubt, mbed-blink from the examples fails in exactly the same way.

Info : clock speed 2000 kHz
Info : STLINK V2J36M26 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.238345
Error: init mode failed (unable to connect to the target)
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked

and for reference I had to add the following lines to blink’s platformio.ini:

[env:nucleo_f439]
platform = ststm32
framework = mbed
board = nucleo_f439zi

Many thanks,
Dave

After a bit more researching, I realised that the stlink / nucleo jumper was open, it is labelled on the board as CN4. These jumpers should be closed, not open!! Even though it shows open as stlink.

After changing the jumpers in CN4 to be closed, I managed to upload:

Info : clock speed 2000 kHz
Info : STLINK V2J36M26 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.243158
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08008b9c msp: 0x20004260
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
** Programming Started **
Info : device id = 0x20036419
Info : flash size = 2048 kbytes
Info : Dual Bank 2048 kiB STM32F42x/43x/469/479 found
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
shutdown command invoked
===================================================================================================== [SUCCESS] Took 56.64 seconds =====================================================================================================


Environment    Status    Duration
-------------  --------  ------------
ATmega2560     IGNORED
Mkr1300        IGNORED
STM439         SUCCESS   00:00:56.644
===================================================================================================== 1 succeeded in 00:00:56.644 =====================================================================================================

1 Like

Even if these jumpers are open, all these do is connect the STLink’s SWD signal to the µC’s SWD signals (or not if they are open), but the STLink itself is still recognized over the USB port regardless of jumper settings.

Glad you figured out the problem.

1 Like

That’s right, it was showing up, but it was impossible to use as a programmer or to interrogate the device fully, and now on reflection I should have caught this earlier, I saw an error text document on the mass storage device it created and ignored it. Thanks for explaining the purpose of those pins, I see exactly what they do now…