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

[Mike_ST]

FIrst try "Under Reset" mode with mode=UR in the command line.

Or

I recommend to script and separate the calls to STM32_Programmer_CLI.exe.

One call for modifying option bytes (rdu)

One call for erasing (-e all) (yes this is redundant with rdu, but you might want to do it anyways if the chip is not protected)

One call for programming & verifiying. (-d %1 -v)

If it doesn't work try to reset the device after each step.

[RAltm]

Hi Mike,

thank you, I'll try it and report the results.

Regards

[RAltm]

@Mike_ST​ ,

I tried it, no luck :\

I used mode=normal as well as mode=ur and also made a try with -hardrst. I divided it also into three steps as suggested by you.

For debugging, I read the option bytes after the script, the option bytes are correctly set. Reading out memory with "-r32 0 1024" also showed up the correct content compared to the .hex file - so is there a chance that something goes wrong inside ST-Link device? I'm on firmware V2J34S7.

Any ideas?

EDIT: I used the CubeProgrammer GUI to only verify against the hex file, that runs okay.

Regards

[Mike_ST]

Ok, another thing is that I would avoid touching option byte memory area when using -v option, I think this is what is leading to mem compare failure....

The answer to that is to have a script with 2 command lines:

• 1st line: unprotecting/erasing/programming/verifying/executing as you wish

STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe -c port=swd freq=4000 ap=0 index=0 mode=[normal/ur] -vb 1 [-rdu] -e all -d Project.hex -v [-s]

• 2st line: program option bytes as desired without -v on the command line

STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe -c port=swd freq=4000 ap=0 index=0 mode=ur -vb 1 -d opt_only.hex

with opt_only (examples for STM32L031):

:020000041FF8E3

:10000000AA005501D90B26F4000BFFF4FB0B04F4F6

:00000001FF

=> unprotect, same effect as rdu option if your flash was previously protected (mem erase) else it won't have any effect

or

:020000041FF8E3

:10000000BB005501D90B26F4000BFFF4FB0B04F4E5

:00000001FF

=> protected.

[RAltm]

@Mike_ST​ 

Hi Mike,

thank you for this suggestion. So, this means to program the flash memory with verification enabled, and the option bytes without verification.

Two questions:

1) do you know a tool which can split the generated .hex file into the sections you suggested? So I could call this tool after build process (the goal is to make as much as possible automatically). I'm not sure if the IDE (Atollic TrueStudio) can output multiple .hex files.

2) for the 2nd command (program option bytes without verification), the option bytes could only be verified by reading them after programming, right?

Any chances that this "programming mode" (having option bytes inside the image) will be implemented into STMCubeProgrammer / ST-Link Utility?

Regards

[Mike_ST]

1) Look for srecord (srec_cat) command, it might be what you need? Or just doing manually once after you have your final software ready, but it depends of your application actually.

2) It seems like the current STM32CubeProgrammer doesn't support the verify option when touching option bytes for now. Actually I think programming is working , but the -v is not possible. I can't tell whether there is a technical reason or not for that.

For your last question of having option bytes inside the image, I think it is working, just -v option is making troubles.

[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

[Mike_ST]

Line 5:  -c port=swd freq=4000 ap=0 index=0 mode=hotplug -vb 1 -r32 0x1FF8000 0x14

I think the reason is that one '0' is missing in the address.

should be -c port=swd freq=4000 ap=0 index=0 mode=hotplug -vb 1 -r32 0x1FF80000 0x14

Best Regards

[Mike_ST]

...

[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 :thumbs_up:

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 :)