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

[RAltm]

@Mike_ST​ 

Yes, it was the missing zero - there's always one little thing which can be missed in front of the final goal :D

Regarding if it was the problem from the beginning, it can't, because reading by -r32 came into the batch file very late.

Now, I think I've solved all my issues - thank you very much 👍

Regards

[Amel NASRI]

Hi @RAltm​ ,

Glag to know that all issues are resolved 🙂

At this level, can you select one of the comments as Best answer?

-Amel

[RAltm]

Done 🙂

[Mike_ST]

Hi Ralf,

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

Regards.

[AShel.1]

Hello RAItm,

how did you generated hex file with option bytes? in STM32CubeIDE I do not see such option available to edit option bytes.

Thanks,

[RAltm]

Hi Ashel,

I wrote a header file where I can configure the corresponding option byte settings. The resulting values are combined into hex values for the option bytes and placed on the corresponding address. This is done by a modified linker script and using __attribute__(section...) on the variables definition. This forces the linker to place the values within the hex file.

Regards

[AShel.1]

Thanks for your prompt reply....can I get some reference source code.

[RAltm]

Hi Ashel,

I attached the files I used for a L011 device, I only removed the informational header. Note that in case of a debug build (symbol _DEBUG defined), the factory settings for option bytes are applied, regardless of the settings in the header file. So, to apply the settings, switch to a release build.

Aside of that, modify your linker script as follows:

For the memory regions, add

OPT_BYTES (r)   : ORIGIN = 0x1FF80000, LENGTH = 32

Add a separate output section for the option bytes:

  /* user option bytes */
  .opt_bytes :
  {
    . = ALIGN(4);
    KEEP(*(.FLASH_OPTR_L*)) /* FLASH_OPTR register */
    KEEP(*(.FLASH_OPTR_H*))
    KEEP(*(.FLASH_WRPROT1_L*)) /* FLASH_WRPROT1 register */
    KEEP(*(.FLASH_WRPROT1_H*))
    KEEP(*(.FLASH_WRPROT2_L*)) /* FLASH_WRPROT2 register */
  } >OPT_BYTES

That should be all what's needed to insert the option bytes into the hex files. Please give feedback.

[AShel.1]

Hello RAItm,

I could generate hex file with option byte data included. now I'm trying to generate DFU file using this hex file and DFU File Manager tool. I thought DFU File manager tool will detect option byte address (0x1FFF000 for STM32F767) and will create separate image for it but it did not.

I'm developing fw update module on host controller(STM32H753) to update fw on slave controller (STM32G473) over SPI. so host will ready DFU file from USB stick will parse it and load it to slave in this I want to write flash and option bytes. do you think any option to separate flash data and option byte on high level.

Thanks,

[RAltm]

Hi Ashel,

I'm not sure if I understand your problem correctly, please check the following:

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

This is part of a batch file which gets the application .elf file passed at position '%1' and which outputs two hex files containing the application and option byte sections. Is this what you want?

Regards