Fail to program STM32F413 using ST-Link Utility (Sector 1 is erased automatically)

[Stefan W]

Posted on April 12, 2017 at 13:56

Hi,

I want to program the STM32F413 with the ST-Link Utility (CLI and UI has the same issue). We have two hex-files. One for the bootloader in the first sectors and one for the firmware in other sectors. Of course no overlapping. Programming always fails. The ST-Link Utility does not report any errors, but when checking the memory after programming both files, sector 1 is always erased. After loading the first hex-files it looks fine, but after loading the second, it is reset to all 1. The other sectors are all okay.

Not an alternative for us, but I also tried to put both hex-files into one. This does not work either. 

Programming the controller with OpenOCD works fine.

To reproduce the behavior:

• Connect to a STM32F413 via ST-Link Utility v4.0
• Set the values of the following addresses to zero: 0x08003FFC, 0x08004000, 0x08007FFC, 0x08008000
• Program a simple hex-file to another sector (like test.hex in attachment)
• Check the values at the addresses above

In my case the values in sector 1 (

0x08004000 and 0x08007FFC) are reset to all 1. The values outside of sector 1 (0x08003FFC and 0x08008000) are still set to zero.

Here some version information:

STM32 ST-LINK Utility.exe   v4.0.0.0

STLinkUSBDriver.dll             v4.4.0.0

ST-Link_CLI.exe                   v3.0.0.0

Firmware Version:                 V2.J27.S0 STM32 Debugger

Any ideas? Could someone please try to reproduce this problem?

#stm32f413vg #stm32-st-link-utility

[Stefan W]

Posted on June 01, 2017 at 09:41

Is anyone already using the 413 and can try to reproduce this please?

I found another, easier way to show this behavior. Just connect to the controller with ST-Link Utility and erase the chip.

Now change values in the memory browser directly. Each time you change a value, all value in the range from 0x08004000 to 0x08007FFF are reset to 0xFF. When changing a value in this range, only the currently changed value is set, all other are reset to 0xFF.

[waclawek.jan]

Posted on June 01, 2017 at 10:46

Ticking 'Skip flash erase' in the dialog which opens upon starting programming won't help?

Not an alternative for us, but I also tried to put both hex-files into one. This does not work either. 

I can't see a way how this could not work. How exactly did you merge the two hexfiles?

JW

[Stefan W]

Posted on June 01, 2017 at 11:19

Thanks for your reply.

Ticking 'Skip flash erase' in the dialog which opens upon starting programming won't help?

No. This does not change anything about this strange behavior.

How exactly did you merge the two hexfiles?

First I merged the hex-files manually with a text editor. But I also wrote both hex-files via OpenOCD into the controller and then stored the memory with the st-link utility in a hex-file.

[waclawek.jan]

Posted on June 01, 2017 at 11:27

Okay so you problem is that you manually edit the content of data-to-be-programmed directly in the St-link Utility, correct?

Can't you edit them elsewhere and then load the edited file and program it without further editing?

I don't say it's not an error in STLink Utility, just trying to find a workaround.

JW

[Stefan W]

Posted on June 01, 2017 at 11:58

No. I do not want to edit data manually. It was just a way to reproduce the problem.

I just want to program two hex-files in two separate memory regions of the STM32F413 with the ST-LINK CLI.

And my problem is that the memory from 0x08004000 to 0x08007FFF seems to be erased during or after programming.

[Tesla DeLorean]

Posted on June 01, 2017 at 13:42

And do either of the .HEX files touch that sector at all? You should validate that they don't.

[Stefan W]

Posted on June 01, 2017 at 14:15

The first HEX-file covers this sector. After programming only this HEX-file the content looks proper (no FF).

But after programming the second HEX-file, which does not touch this sector at all, or after programming the merged HEX-file, this sector is reset to all 1 again.

I know that this does not make much sense. It would be very helpful, if someone could try to reproduce this, so that I can see, if I am doing something wrong or not.

[AvaTar]

Posted on June 01, 2017 at 14:29

Not sure if this is an option, but Segger offers a JLink firmware for STLink devices.

And my experiences with Jlink are nearly all positive. Especially it proved clever enough not to touch unchanged Flash sectors.

[Stefan W]

Posted on June 02, 2017 at 09:32

It seems as if the ST-LINK Utility erases Sector 1 on nearly each action like direct write to memory or calculating memory checksum.

I am still looking for a solution, but I finally found a workaround, that could work for me. Instead of programming the hex-file for the bootloader and then the hex-file for the firmware, I program the firmware first. So the programming of the bootloader and of sector 1 is the last action performed by ST-LINK CLI. This way sector 1 is still written after the whole programming process has finished.