2013-09-20 05:35 AM
Hello there,
Apparently the 96 bit unique device id is not unique for STM32L1x family of devices.Or is it supposed to be absolutely unique between devices?I have at least 2 devices on my desk, with the same 96 bit number.Any explanation for this?Best regardsGestur #no-hablo-hal #stupid-as-designed2013-09-20 06:27 AM
Further information:
Devices are all STM32L151C6T6, revision Vpackaging info ''GH254 VG'' and CHN309All 3 devices show exactly the same values for the uniqueid registers(gdb) x /3x 0x1FF80050 0x1ff80050: 0x0e473233 0x30343433 0x7b747800(gdb) x /3d 0x1FF80050 0x1ff80050: 239546931 808727603 2071230464(gdb) Sincerely,Karl P2013-09-20 08:15 AM
You understand the unique number is NOT 3 linear words, but
0x1FF80050 0x1FF80054 and 0x1FF80064 !!! right?2013-10-02 05:52 AM
Was just coming back to update this post. Yes, we were looking at the three contiguous words. When we correctly followed the L1 ref man, and used different addresses for the different parts of the UID register, it was indeed unique.
Of course, on the F0,f1,f2,f3,f4 it's three contiguous registers, and it's all ''software compatible'' right?! So good job ST on the L1.Oh yeah, and the L1M+ and HD have a _different_ discontiguous set of registers.So yeah, we failed to read the reference manual, but ST failed pretty hard at being sane. :(2013-10-02 08:22 AM
I agree it's a bit stupid, but it is documented behaviour.
I'm not sure of the rational, this OTP/FLASH area is filled with other die site and part specific data, most of which isn't documented.2016-11-11 01:24 AM
Documented behaviour that even ST doesn't read. Here is a bugged function from stm32l1xx_ll_utils.h of the STM32L1xx_HAL_Driver:
__STATIC_INLINE uint32_t LL_GetUID_Word2(void) { return (uint32_t)(READ_REG(*((uint32_t *)(UID_BASE_ADDRESS + 8U)))); }2016-11-11 08:27 AM
I seem to recall the L1 series having two different unique mappings depending on the stepping/functionality. There are a host of reasons why I'm not a HAL user..