Skip to main content
RAltm
RAltm
Senior
August 21, 2019
Solved

Option bytes in HEX file - verify fails

  • August 21, 2019
  • 13 replies
  • 9153 views

Hi,

I'm using latest STMCubeProgrammer/ST-Link-Utility releases. My goal is to provide the option bytes directly in the .elf/.hex file, so our manufacturing department only needs to download this file.

I already managed to get the settings into the .elf/.hex file automatically. But when I try to program the device, I got verification error. It seems(!) that the device is programmed correctly, but I want to be sure.

The device is a L011F4. There are two configurations for the option byte corresponding to the debug and release builds. For the debug build, the option bytes are the same as for a blank device delivered from factory. For the release build, the RDP level is 1, and the bootloader pin is disabled. No write protection fro both configurations.

Even for the debug build with no RDP, the verification fails and I don't know why. Here's my call to STM32_Programmer_CLI.exe:

-c port=swd freq=4000 ap=0 index=0 mode=normal -vb 1 -rdu -e all -d %1 -v

%1 is replaced with the name of the .elf/.hex file. I know that "ap=0" and "index=0" are the default values, this is just for possible extension in the future (parallel programming, etc.). The same for the verbosity level, this is for debugging the script. I'm not sure if "-e all" is redundant since "-rdu" should completely erase the device automatically if I'm understanding it correctly. -v is to definitively verify the download.

This is the content of the debug .hex file after the application data area:

:020000041FF8E3 => set upper address bytes (0x1FF8, location of the option bytes)

:10000000AA0055FF70808F7F0000FFFF0000FFFFF8

:040010000000FFFFEE

:04000005080039A90D

:00000001FF => end of hex file

This should set FLASH_OPTR@0x1FF8000/4 = 0x807000AA (default value) and the FLASH_WRPROT1 & 2 registers @0x1FF8008/C/10 to no write protection. Also the inverse bits in the upper half-word are included.

With the above script, according to the output from STM32_Programmer_CLI.exe, resetting the RDP level, mass erase and download are fine, but verification stops at the second byte:

Verifying ...

Read progress:

███▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 6%

Error: Data mismatch found at address 0x08000001 (byte = 0x00 instead of 0x08)

Error: Download verification failed

Since RDP is reset, it should be possible to verify the device.

When using the older ST-Link Utility, there seems to be no way to reset the RDP level easily, and using the GUI version of STMCubeProgrammer to verify if my script might have an error looses the connection (and additionally it seems that there's no way to inhibit the option byte programming with the settings from GUI).

So, I'm a bit at a loss what might go wrong :\ Any ideas?

Regards

This topic has been closed for replies.
Best answer by RAltm

@Mike_ST​ 

I think I found a solution - not using srecord, but objcopy. Here's my batch file:

arm-atollic-eabi-objcopy.exe -O ihex -R .opt_bytes %1 Image.hex
arm-atollic-eabi-objcopy.exe -O ihex -j .opt_bytes %1 OptBytes.hex
STM32_Programmer_CLI.exe -c port=swd freq=4000 ap=0 index=0 mode=normal -vb 1 -rdu -e all -d Image.hex -v
STM32_Programmer_CLI.exe -c port=swd freq=4000 ap=0 index=0 mode=hotplug -vb 1 -d OptBytes.hex
STM32_Programmer_CLI.exe -c port=swd freq=4000 ap=0 index=0 mode=hotplug -vb 1 -r32 0x1FF80000 0x14
STM32_Programmer_CLI.exe -c port=swd freq=4000 ap=0 index=0 mode=hotplug -vb 1 -ob displ
del Image.hex
del OptBytes.hex
  • Lines 1 & 2 split the .elf image into a pure code and a option byte only .hex file (I used hex output because it enables me to verify the output). The objcopy executable is from Atollic TrueStudio.
  • Line 3 removes RDP, erases the device, then downloads and verifies the code
  • Line 4 downloads the option bytes
  • line 5 should give me option bytes only in a 4-byte hex value (see question below)
  • line 6 reads option bytes and flash protection bytes
  • lines 7 & 8 delete the splitted files - this is to ensure that those files aren't used seperately by accident.

So, I think there's only question left, it's about line 5: I wanted to read the option bytes by -r32 option because the output is short and can easily be parsed, but it throws an error. Using line 6 is able to read the option bytes and gives me the expected information, but in a more human readable form. It can't be parsed easily - any idea how I can get the option bytes in a simple 4-byte hex value?

Regards

13 replies

Show previous replies
Mike_ST
Mike_ST
Technical Moderator
August 23, 2019

Hi Ralf,

FYI, internal ticket entered, maybe it will be fixed in case this is an actual problem or just a technical limitation.

Regards.

BSchm.8
BSchm.8
Visitor II
May 4, 2023

I had a similar problem, but solved it in a different way. I had a hex file which included an application and option bytes. (Created in IAR, via adding a optionbytes.s file to the project.) CubeProgrammer (2.13.0, most recent as of May 4th, 2023) will program my hex files, but the verify would fail. When it got to certain option bytes, the value read back was different from the value in my hex file. Based on this thread, I thought it was a problem with CubeProgrammer, and so I split my hex file into two parts, and programmed both that way, and simply didn't do a verify on the optionbyte hex file. But that didn't feel good.

So I discovered that everything works just fine in a single big hex file. The trick is to make sure that your option byte values in your hex file have the proper values for the 'reserved' bits. Sometimes they are not what the datasheet says. So I used CubeProgrammer to read out the option byte section of flash, then set my optionbytes.s file to mimic those bits (just for the reserved bits of each option byte). This allowed CubeProgrammer (both CLI and GUI) to properly verify the application AND option bytes and everything is working great now. Our project has five STM32s (of 3 different types) and this method worked fine on all of them.

RAltm
RAltmAuthor
Senior
May 5, 2023

Hello BSchm,

thank you for this information, I'll use this approach on the next project.

Regards

Terms & ConditionsAccessibility statement