OTP area in flash is not empty on brand new STM32WB5MMG

[burn_]

Good day,

On a brand new SMT32WB5MMG MCU, I have found that the One-Time Programmable area is not empty. See the image. The OTP area starts at 0x1FFF7000. There is also some data right before the OTP area - what is that doing there as well?For context, I'm using the STM32WB5MMG in a custom application (i.e. not a NUCLEO board). I have seen the same issue (and the exact same data) on two different boards.

I did not encounter this issue when using an STM32WB55RGV6 previously.

Has anyone else encountered this?

[Remi QUINTIN]

The 28KB bank ahead of the OTP area is the system memory starting from 0x1FFF0000 to 0x1FFF6FFF.

The system memory holds the boot code from which the CPU1 boots in system memory boot mode.

The area is reserved and contains the boot loader used to reprogram the Flash

memory through one of the following interfaces: USB, USART1, I2C1. It is programmed

by STMicroelectronics when the device is manufactured, and protected against

spurious write/erase operations. For further details, refer to the AN2606 available

from www.st.com.

[Tesla DeLorean]

In vacuum sealed packaging from an ST production site, direct to you?

Or some other path, or distribution, of less known provenance?

Would suggest you provide lot and trace codes to @Remi QUINTIN​ via PM and perhaps ALL top side markings on the ICs in question

[burn_]

Hey @Remi QUINTIN​ , thanks - it makes sense that the STM bootloader is located there.

And thanks @Community member​ for the suggestion, I'll send details through to Remi.

[Remi QUINTIN]

I got your details. both markings of those modules are the same which is not surprising.

Regarding the values already present at the start of the OTP area, this could come from some HSE clock trimming operations done at manufacturing level. The UID (Universal ID that helps identify the type of device) is also located somewhere in the OTP Area.

I need to check the map of those values to understand if they can match with your extract.

Note that anyhow, it is not a bug and this situation should not create any issue for your development.

[Remi QUINTIN · Accepted solution]

For parts from the WB family, we write in OTP area the following information:

• Module ID
• HSETUNE trimming information

Address: 0x1FFF7000h / Data: 0xFFh (assuming 0xFFFF for module board identifier)

Address: 0x1FFF7001h / Data: 0xFFh

Address: 0x1FFF7002h / Data: 0x05h device ID

Address: 0x1FFF7003h / Data: 0xE1h Company ID

Address: 0x1FFF7004h / Data: 0x80h Company ID

Address: 0x1FFF7005h / Data: 0x00h Company ID

Address: 0x1FFF7006h / Data: 0x19h trimmed HSETUNE[0:5]

Address: 0x1FFF7007h / Data: 0x00h index

HSE trimming is normally done by user once the Crystal is mounted. For Modules (where Crystal is embedded) we were asked to do this trimming at final test (FT) and store it in the OTP.

Hope that clarifies.

[Tesla DeLorean]

Strikes me that the module level implementation needs the usage/shrinkage of the available OTP space to be better documented.

The STM32WB55xx Reference Manual doesn't address STM32WB5MMG usage, neither does the STM32WB5MMG data sheet / errata.

[Remi QUINTIN]

The details below pertain to the module. There are 2 separate sets of documents for the standalone chip and the module.

Indeed we should add this info in the datasheet.

Note that this 1 Kbyte (128 double words) OTP (one-time programmable) area is for user data and only two double words are used out of manufacturing.

[burn_]

Thank you for the clarity @Remi QUINTIN​. It makes sense that HSETUNE data needs to be written in the OTP area for a module.

And yes, I agree that it definitely ought to appear in the SM32WB5MMG datasheet.

It does, however, affect my implementation somewhat. I make use of the OTP area to store the product's serial number. But STM now assumes a defined structure for data in the OTP area, as given in the CubeMX generated otp.h and otp.c (see the OTP_ID0_t struct). A given serial number may be misinterpreted as the id field, and thereby the wrong HSETUNE values will be read!

@Remi QUINTIN​, would you be able to please file a request with the folks writing the HAL libraries to at least add user sections to the otp.c and .h files, so that a custom implementation can be done? And at best, add some more flexibility as to how the OTP area is used.

[Remi QUINTIN]

If think there is a misunderstanding there.

The OTP_ID0_t struct is only for the first part of the OTP area. The retrieval of the BdAddress in app_ble.c file or the reading of the HSE trimming value in main.c file are the only functions using this structure.

Then all the remaining OTP area is for your own usage to store value you want to save.

Once written, you get an id for the position of the OTP DWORD that your value is written at.

You just have to use the same id to reprieve your value.

Thee fact that the start of this OTP area is used for ST usage should have no impact on your application. The OTP_ID0_t structure is really meaning less for your own storage of value.