Skip to main content
Associate II
October 7, 2023
Question

Is there somewhere to write custom data that isn't overwritten by the bootloader?

  • October 7, 2023
  • 7 replies
  • 1966 views

I want to be able to program a STM32H7 device with something like a device ID, for example, this device is #10, and that devices is #55. This would affect the behavior of the device, so it must be possible to read that number through the firmware, so that the device is aware of which number it is.

I also want to be able to update the firmware on all devices through the built-in UART bootloader, but I don't want this to wipe the device ID. Is it possible to do something like this without adding an external FLASH?

This topic has been closed for replies.

7 replies

Tesla DeLorean
Guru
October 7, 2023

Isn't there some OTP memory?

Read Unique ID?

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
Associate II
October 8, 2023

I think OTP will work. Unique ID won't work because it needs to be a specifically programmed number that changes a delay in communication.

Can OTP be rewritten during development or is it truly a one-time thing?

AScha.3
Super User
October 7, 2023

..and if battery Vbat there, the backup sram .

If you feel a post has answered your question, please click on " Best Answer ".
Pavel A.
October 7, 2023

As @tesla suggested, STM32 has built-in unique ID, 96 bits (3*32). Can you use it? 

Pavel A.
October 8, 2023

OTP is truly one-time. If this weren't bad enough, STM32H7 does not have OTP at all.

MM..1
Super User
October 8, 2023

Based how H7 but maybe this helps STM32H7-Memory-Flash (FLASH) have options area 2k

Or if you have spare sectors can use EEPROM emulation ...

And bootloader overwrites only by commands, not all space.

TDK
October 8, 2023

Despite the marketing materials, there is no nonvolatile memory store on the STM32H7 apart from the normal FLASH. The "2KB flash of user option bytes for user configuration" mentioned in the datasheet is presumably a disconnect between what is technically on the chip and what is available to the user and it should be embarrassing to ST that it has not yet been corrected.

https://community.st.com/t5/stm32-mcus-products/how-to-access-the-2kb-user-option-bytes-in-h7/td-p/293387

https://community.st.com/t5/stm32-mcus-products/how-to-write-non-reserved-option-bytes-on-stm32h750xx-mcu/m-p/170614

https://community.st.com/t5/stm32-mcus-embedded-software/location-of-mac-address-storage-in-stm32h7-memory/td-p/169834

Would love to be proven wrong here, btw, but all evidence points to the contrary.

Also see (for the L5):

https://community.st.com/t5/stm32-mcus-products/stm32l5-user-option-byte-access/td-p/151170

 

"If you feel a post has answered your question, please click ""Accept as Solution""."