STM32CubeIDE updated stlink on a stm32H743-EVALv2 board to V3J4M2, but then is unable to program the board.

Brian Khuu · ‎2019-10-20

Was able to program the board previously, but today after updating my STM32CubeIDE, it refused to run debug until I updated the stlink on my dev board.

But upon doing so, it gave these error. Essentially meaning I cannot program my dev board.

```

STMicroelectronics ST-LINK GDB server. Version 5.3.2

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

Waiting for debugger connection...

Debugger connected

-------------------------------------------------------------------

STM32CubeProgrammer v2.2.0

-------------------------------------------------------------------

Log output file: /tmp/STM32CubeProgrammer_TqQf5t.log

ST-LINK SN : 002F001F3137511233333639

ST-LINK FW : V3J4M2

Voltage : 3.28V

SWD freq : 24000 KHz

Connect mode: Under Reset

Reset mode : Hardware reset

Cannot identify the device

Error: unknown or unsupported device (DevID = 0x0000)

Memory Programming ...

Opening and parsing file: ST-LINK_GDB_server_QKNgwM.srec

File : ST-LINK_GDB_server_QKNgwM.srec

Size : 157296 Bytes

Address : 0x08000000

Erasing memory corresponding to segment 0:

Download in Progress:

File download complete

Time elapsed during download operation: 00:00:00.199

Verifying ...

Error: Data mismatch found at address 0x08000004 (byte = 0x31 instead of 0x5D)

Error: Download verification failed

Encountered Error when opening /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.macos64_1.1.0.201910081157/tools/bin/STM32_Programmer_CLI

Error in STM32CubeProgrammer

Debugger connection lost.

Shutting down...

```

I am running this IDE on a mac on MacOS catalina. Oh and btw I still cannot run latest STM32CubeProgrammer on mac, even after updating java to latest version.

Ayberk Özgür · ‎2019-12-04

I noticed that this problem seems to occur for me when there is unreachable code left somewhere due to testing. I'm using `-O3` and this code doesn't seem to be optimized out by gcc which makes the programmer complain somehow. I didn't test it further. Quick solution seems to be to comment out these sections if possible, or switch to OpenOCD.

MMuri.1 · ‎2020-01-03

Found a fix! I am also running the STM32CubeIDE on mac and running into this issue. I remember I had to do some funky thing when installing STM32CubeIDE on OSX Catalina, not sure if that had something to do with the programming not working. From googling around it seems like other users only encounter this problem with Catalina, not previous releases. I really can't believe that ST does no continual testing on their products when new OS's are released. Or if they do, that they are slower than the community fixes here...

The fix is to set the programmer to ST-LINK (OpenOCD) instead of ST-LINK (ST-LINK GDB Server), see screenshot below. The OpenOCD debugger seems to be able to auto-negotiate a speed that works with the debugger.

jpnorair · ‎2020-01-21

This is actually a very common problem with MANY STM32 dev kits. It's not even a Mac issue, it's an issue with ST loading STUPID demo firmware onto the boards, which disables the ALT state of the SWD pins as it runs. The STLink FW is apparently too slow to catch the chip during startup, before it applies these bad settings.

Anyway, use STLINK (OPENOCD) mode the first time you load your code. Set this in the "debug configurations". Get rid of ST's garbage demo firmware. Then you can go back to the much better STLINK (STLINK GDB SERVER) mode, for the second time.

Ayberk Özgür · ‎2020-01-22

This is certainly not the case for me. I kept having the problem as long as I had some unreachable code around, regardless of how many times I went back and forth between gdb and openocd.

jpnorair · ‎2020-01-23

I can confirm that this is a problem also for Mojave (the previous OS release). The specific issue is that STLink v2 fails to write to flash. If you load the firmware via OpenOCD, you can exit debugger and re-open with STLink v2 -- it will work.

This is not so much a solution as it is an identification of what the problem is -- the latest STLink FW cannot write to flash.

I can also confirm that I have no luck accessing my specific device (Nucleo L412) on Windows, either. This new STLink driver and FW simply weren't tested. I wish there were a way to roll it back without CubeIDE complaining.

mur · ‎2020-03-01

This issue is happening to me with a NUCLEOF334. Not nice.

As some other user pointed out, it is depending on what you are programming. Right now, I can reproduce the issue by adding or removing a single line of code.

main.c
------------
 while(1)
{
[code...];
 
disablePWMs(); //BUG CREATION line
 }
 
 HRTIM_HandleTypeDef* getTimerObjectHandler(void)
{
	return &hhrtim1;
}
 
externalModule.c
-----------------------------
 
void disablePWMs(void)
{
	HAL_HRTIM_WaveformOutputStop(getTimerObjectHandler(), HRTIM_OUTPUT_TA1 | HRTIM_OUTPUT_TA2 | HRTIM_OUTPUT_TD1 | HRTIM_OUTPUT_TD2);
}

by commenting or adding the line, the problem happens or not.

If the HAL is accessed from main.c, there is no issue programming:

main.c
------------
 
 
while(1)
{
[code...]
 
HAL_HRTIM_WaveformOutputStop(&hhrtim1, HRTIM_OUTPUT_TA1 | HRTIM_OUTPUT_TA2 | HRTIM_OUTPUT_TD1 | HRTIM_OUTPUT_TD2);
}

Tesla DeLorean · ‎2020-03-01

Probably had a different set of issues. This relates to ST-LINK/V3

Be specific about the firmware and drivers in use, and the frequency of the SWD connection. Use 4 MHz rather than 24 MHz

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

SFrin · ‎2020-11-14

I have the same issue. STM Cube Programmer ready always device ID 0x0000 from my BluePill Boards as well as Nucleo64-F103 Boards via SWD but other Programs work fine.

SFrin · ‎2020-11-14

I just did another test with a Nucleo64-F103 which also shows the same issue. After cube programmer reports device ID 0x00000 other programs show me problem with the USB communication to ST-Link. I have to unplug the ST-Link to get it back working.

SFrin · ‎2020-11-14

Dear Admin, pleas delete my previous post. It belongs to another thread.