Storing per-device info on STM32H563 for shared firmware

[JuiHung]

Hi,

I’m developing an application on multiple STM32H563 units on the same board. Although all units use the same firmware, the logic depends on each unit’s position, so I need a way to identify which unit it is.

Currently, I program the full flash memory (.bin/.elf) with STM32CubeIDE or STM32CubeProgrammer. Is there a standard or recommended way on STM32H563 to store small per-device information (like unit ID or role) separately from the main application flash, so the firmware can read it at startup?

 

Thanks for any guidance!

[mfgkw]

Hi,

you have the choice...

There is a 96 bit unique id.

Or you can write something to 2kB one time programmable (OTP) memory.

[JuiHung]

Hi,

 

Thanks for your reply. We’d prefer not to use OTP for now, as we’re still in development. For the 96-bit unique ID, is there any official documentation or recommended method to read or write it on STM32H563?

Also, is this ID read-only? If so, would it be unsuitable for our needs, since we want to store user-defined, writable information per device?

 

Thanks!

[mfgkw]

The Id is only readable (via register or HAL functions). See https://community.st.com/t5/stm32-mcus/how-to-obtain-and-use-the-stm32-96-bit-uid/ta-p/621443

You can not modify it, but you can write your code to behave differently depending on known ids.

 

For writing user defined values you can use OTP or flash. Using flash usually wastes much space for a small amount of data.

 

Or attach external EEPROM like 24(LC)... with I2C or 25(LC)... with SPI.

 

 

[JuiHung]

Thanks for your reply and the information. Based on what you mentioned, we would like to use flash for storing user-defined values. Is there a standard way to organize a flash block for user-defined data that won’t be overwritten by firmware programming (with STM32CubeProgramer using .elf file generated by STM32CubeIDE build), and that can be flashed independently from the main firmware?

[mfgkw]

I do not know about a common standard for this.

By default flash is used starting from low addresses to higher. So as long as you do not use it up for code etc. you can use the last page(s) as you like.

So you can write these page(s) either per program at runtime or with ST-Link from outside.

(Maybe it is a good idea to lower flash size in the ld file or reserve the area there. Then you get errors when your code and data grows too high and threatens your private flash data.)

 

[mfgkw]

P.S.:

 

- Be sure not to collide with dedicated areas of your slash memoy (OTP or such). So study the reference manual RM0481 https://www.st.com/resource/en/reference_manual/rm0481-stm32h52333xx-stm32h56263xx-and-stm32h573xx-armbased-32bit-m

 

- It is up to you how you organize your data. Either you see the flash memory as a stream and keep your data as text like "min=12\nmax=155\0", or you define a struct with your values as layout.

 

- If you want to change your data at runtime you can not change the area partially. Instead you have to erase the whole page (8kB here AFAIK) and rewrite it with your complete changed data.

 

- If you change daIt is yourta at runtime and need to be sure to always have a valid configuration you must reserve at least two pages and add a counter to your data set and maybe a check sum. Then to read the data look at both/all pages and see which of them is valid has the highest counter. To write new data take an invalid page or the one with low counter and rewrite this page with new data along with an incremented counter.

 

(And keep in mind that flash can not be rewritten unlimited. If you rewrite it each second you should have a look on its estimated lifetime.)