STM32G030 spare option bytes

[DAlbe.3]

I have a small amount of per-device data (e.g. hardware revision, serial number, manufacture date) that I would like to store persistently in an STM32G030 without consuming a 2K flash sector.  Obviously one option is OTP, but I'm curious about the Flash Option bytes and have a few questions:

1. What option byte addresses (if any) are available to hold user data.  The manual indicates that there are 128 option bytes at 0x1FFF7800, writable as 64-bit double-words.  The manual also shows a memory map listing the purposes of bytes 0x1FFF7800..0x1FFF782F, but no information is given about locations 0x1FFF7830..0x1FFF787F and I'm hoping those are available.

This site (https://wiki.segger.com/ST_STM32G0) indicates that the STM32G0x0 only has 96 option bytes from 0x1FFF7800 - 0x1FFF785F rather than 128; I don't see anything about this in the manual; is it true?  In that case, the available range might be 0x1FFF7830..0x1FFF785F. 

From a stock uC, I note that the words at 0x1FFF7830 and 0x1FFF7870 are set to 0x00000000 (and presumably their complement words are set to 0xFFFFFFFF) are these used for anything?  The double words from 0x1FFF7838 to 0x1FFF786F appear unused (all 0xFFFFFFFF) as well as the double word at 0x1FFF7878; are they available to store user data?

2. Is the complement model required for double words or is that just how the system bootloader implements a modicum of data integrity checking?  (i.e. do I need to store each double word as a long word and its complement?)

3. Is there an easy way to program OTP or option bytes using off-the-shelf tools such as STM32CubeProgrammer?

[TDK]

1+2) There is no user-available non-volatile memory available to store data, despite vague suggestions in the RM and datasheet. The only option bytes accessible are those specified in the reference manual.

3) Have you tried writing it like you would any other part of memory? I don't believe there is any OTP-specific interface.

[DAlbe.3]

Thank you for the quick reply @TDK; it's disappointing then that ST publicizes 128 (or 96) bytes of option bytes in so many places in the RM.

It seems that my only choice then is the OTP at 0x1FFF7000. 
https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer_OTP_management#Write_OTP_with_download_command

Fortunately, I have at least a few hundred of these uCs on hand to experiment with until I get things right :)

[Andreas Bolsch]

The option byte area at 0x1FFF7800 is not user writeable/eraseable but only via the flash option registers. When option bytes are to be written, the new contents have to be written to the option *registers*, and when initiating the write prodedure, the option byte area is erased (probably the whole area) and the register contents automatically copied to this area. So no chance to use the "unused" parts of this area, and hence there is no point in argueing about the actual size of this area. Most likely it's size is an even power of two for technical reasons.

 

BTW Due to this erase-whole-block-then-write-whole-block behaviour option bytes modification is a rather delicate procedure which should only be done in a safe environment (and in particular not on a regular basis).

[DAlbe.3]

Thank you @Andreas Bolsch; I appreciate the quick reply.

I guess the factory data is going in OTP then.

[Pavel A.]

@DAlbe.3 the wiki article you're found is applicable to the STM32MP1 family.

[DAlbe.3]

Thanks to @TDK and @Andreas Bolsch for the quick response; their responses made it clear that the option-byte region is not usable for my purpose.  I ultimately implemented a solution in OTP, storing data in signed, time-stamped records so I can (if needed) update information a few times before running out of OTP.

STM32CubeProgrammer programs OTP easily (no different from flash) and so the OTP solution has worked out nicely for factory data or other data that is (mostly) immutable.

[sireevenkat1]

Hi @DAlbe.3 ,

---

I ultimately implemented a solution in OTP, storing data in signed, time-stamped records so I can (if needed) update information a few times before running out of OTP.

---

May I know how do you implemented above application with OTP.I am also struct with storing serial number and other data in OTP/Option byte. Now I am thinking to go with OTP.

Can you share the any reference links or tips you followed for flashing the serial numbers in to OTP memory.
It will be helpful.
Thanks

[DAlbe.3]

Hi @sireevenkat1 ,

The STM32CubeProgrammer software is able to program OTP memory exactly the same way as flash memory: generate a hex file containing the data you want in OTP at the proper addresses, load it into STM32CubeProgrammer, and flash your target.

You can convert a binary data file containing the OTP information you want to write into a hex file located at the proper address using the objcopy utility that's part of the ARM development toolchain (or most embedded toolchains):

# Convert binary file (outbin) to hex file (outhex) located at OTP address: 0x1FFF7000
arm-none-eabi-objcopy -I binary -O ihex --change-addresses 0x1FFF7000 $outbin $outhex

I hope this helps, feel free to ask questions...