Skip to main content
Visitor II
April 12, 2017
Question

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

  • April 12, 2017
  • 4 replies
  • 3783 views
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
    This topic has been closed for replies.

    4 replies

    Stefan WAuthor
    Visitor II
    June 1, 2017
    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.

    Super User
    June 1, 2017
    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 WAuthor
    Visitor II
    June 1, 2017
    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.

    Super User
    June 1, 2017
    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 WAuthor
    Visitor II
    June 2, 2017
    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.

    ST Employee
    July 18, 2017
    Posted on July 18, 2017 at 14:40

    Dear All,

    Sorry for the late reaction. This bug is already fixed. The MCU support can share with you the patch for the ST-Link Utility v4.0.0.0 or it will be in incoming version of ST-Link Utility.

    Have a nice day, Ondrej

    Super User
    July 18, 2017
    Posted on July 18, 2017 at 14:47

    Ondrej,

    OT:

    Will the new version also have the

    https://community.st.com/0D50X00009XkaBMSAZ

    facility implemented?

    Thanks,

    Jan

    ST Employee
    July 19, 2017
    Posted on July 19, 2017 at 11:47

    Dear Jan,

    I have no information about the plan of manual target reset in ST-Link Utility.

    Have a nice day, Ondrej