Option bytes in HEX file - verify fails

[RAltm]

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

[AShel.1]

Hello RAItm,

1. @arm-atollic-eabi-objcopy.exe -O ihex -R .opt_bytes %1 Application.hex
2. @arm-atollic-eabi-objcopy.exe -O ihex -j .opt_bytes %1 OptBytes.hex

I believe these commands will generate application and option byte specific files, similar thing I want to generate from my project ....a file with application data and 2nd file only with option byte data.

unfortunately above commands cannot be used in STM32CudeIDE, I'm trying to search similar commands for STM32CubeIDE

[RAltm]

Hi Ashel,

I'm pretty sure they can be used in any IDE which support pre- and postbuild commands 😉 It's within "C Build => Settings => Build Steps" in CubeIDE.

The above executable is the one which is delivered with Atollic TrueStudio, CubeIDE will have the same, but with another name. Search for an executable containing 'objcopy' within your CubeIDE installation folder. If you want to execute this within CubeIDE, you might want to use predefined parameters reflecting the location of your project folder and output files, etc. and maybe you've to specify the absolute path to the objcopy executable.

Regards

[AShel.1]

Hello RAItm,

I could create option byte hex file with

arm-none-eabi-objcopy.exe -O ihex -R .opt_bytes ${ProjName}.hex Application.hex; arm-none-eabi-objcopy.exe -O ihex -j .opt_bytes ${ProjName}.hex OptBytes.hex

but I see option byte data is missing from it.

If I create application + option byte file together then at the end of the file I see,

:020000041FFFDC

:10000000F0AA0000FFFF0000800000004000000098

:0400000508001AFDD8

:00000001FF

and with this command arm-none-eabi-objcopy.exe -O ihex -j .opt_bytes ${ProjName}.hex

I see only below part is left in OptBytes.hex file.

:0400000508001A0DC8

:00000001FF

[RAltm]

Hi Ashel,

as far as I can see, you're using the complete hex file as input for objcopy. I told you to use the .elf file. A hex file has no information about sections, therefore objcopy is not able to retrieve the sections. I assume this is causing your problem.

EDIT: you're also using a different device. Did you change the option byte addresses in linker script, etc.?

Regards

[AShel.1]

Working now 🙂

thanks for your prompt support

[RAltm]

Glad that I could help. Have a nice weekend.

[BSchm.8]

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]

Hello BSchm,

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

Regards