Visitor II

Question

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

Forum|Forum|6 years ago
October 20, 2019
21 replies
8390 views

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.

This topic has been closed for replies.

Show previous replies

H

hansd56

Visitor II

No problems here. Board Nucleo-H743ZI2 CubeIDE 1.1

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

InitWhile : Enabled

Waiting for debugger connection...

Debugger connected

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

STM32CubeProgrammer v2.2.0

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

Log output file: C:\Users\hansd\AppData\Local\Temp\STM32CubeProgrammer_a16280.log

ST-LINK SN : 002000463137510939383538

ST-LINK FW : V3J4M2

Voltage : 3.30V

SWD freq : 24000 KHz

Connect mode: Under Reset

Reset mode : Hardware reset

Device ID : 0x450

Device name : STM32H7xx

Flash size : 2 MBytes

Device type : MCU

Device CPU : Cortex-M7

Memory Programming ...

Opening and parsing file: ST-LINK_GDB_server_a16280.srec

File : ST-LINK_GDB_server_a16280.srec

Size : 5500 Bytes

Address : 0x08000000

Erasing memory corresponding to segment 0:

Erasing internal memory sector 0

Download in Progress:

File download complete

Time elapsed during download operation: 00:00:01.052

Verifying ...

Download verified successfully

R

RBoer

Visitor II

Same here, everything worked fine with STM32CubeIDE originally installed on mojave and a few weeks ago upgraded to 1.1.0 on macOS catalina. Was working fine even today, uploaded/debugged multiple times, up until the point where it forced me to update the firmware of the stlink-v2 and after that the problems started.

Error: Data mismatch found at address 0x08000188 (byte = 0x00 instead of 0xFF)

Error: Download verification failed

Downgraded the firmware to to V2J33S7 using an older st-link utility which I had installed in the vm, but then cubeIDE on OSX insists again on upgrading to V2J34S7

Downloaded stsw utility which can upgrade to an even newer version V2J35S7, but the above errors when debugging remain.

Accessing, clear, write/verify using stm3cubeprogrammer works fine within a vmware virtual machine.

Installed stm32cubeide 1.1.0 in the windows-VM and it also works, without any problems on stlink-v2 with fw V2J35S7...

stm32cubeIde on macOS seems to be unusable/broken now.

Disappointing, because I actually liked it (while it worked).

Note: Stm32cubeprogrammer also doesn't work under osx, there's other posts in the forum reporting on that, something with java - gave up on getting that to work.

B

Brian KhuuAuthor

Visitor II

Just in case people are still having problems. I've bypassed the problem by using OpenOCD on my mac. To use OpenOCD, you could refer to my example repo below

https://github.com/mofosyne/stm32h7xx-cubemx-makefile-openocd-gdbgui-example

This may not work for those who need to use an IDE, but if you are in a bind. This may help.

To program `make swd`

To debug with gdbgui `make swd-gdbgui`

To see the commands I used for `make swd` check https://github.com/mofosyne/stm32h7xx-cubemx-makefile-openocd-gdbgui-example/blob/master/Makefile#L214

Feel free to poke me if you have any issues.

B

Brian KhuuAuthor

Visitor II

Also take note that in Spaced Cowboy's thread, two individuals was able to switch their IDE to use OpenOCD, so you can use that option as well.

> Hey, I had the same issue and resolved it by setting Debug Configurations -> Debugger -> Debug probe = ST-LINK (OpenOCD)

> I can confirm: changing `ST-LINK (ST-LINK GBD server)` to -> `ST-LINK (OpenOCD)` does work!!!

A

Ayberk Özgür

Visitor II

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.

M

MMuri.1

Visitor II

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.

J

jpnorair

Visitor II

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.

J

jpnorair

Visitor II

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.

A

Ayberk Özgür

Visitor II

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.

M

mur

Visitor II

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);
}

T

Tesla DeLorean

Graduate II

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

S

SFrin

Visitor II

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.

S

SFrin

Visitor II

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.

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded