How to read STM32 UID from ST-Link ?

[acapola]

I have seen that STM32_Programmer_CLI has a "getAuthID" but it seems this reads something else than the UID available to software. 

I know I can do 

 

STM32_Programmer_CLI --connect port=swd index=0 -halt --optionbytes displ --blankcheck -r32 0x0BFA0700 12

 

but it is likely to work only on STM32U5 and I guess it make sense to have a generic way to read that.

Is there a better way to read that UID from ST-Link ?

[STOne-32]

Dear @acapola ,

Not sure to understand the question, each STM32 MCU and serie has a Unique ID and is located at a base address - in Device Signature chapter in the reference Manual .

for example for STM32G0 it is at : 0x1FFF 7590 and is 96-bits wide .  We can read that address if course using SWD and CubeProgrammer. 

You can implement a script having the map file of each series Device ID and the base address of the Unique ID and then This is possible to extract in automatic way .

Let me know if it helps ,

Ciao

STOne-32

[acapola]

so from your answer I understand that ST expects everyone to implement a script that detect the device type, lookup the address of UID for that device type and finally issue the appropriate read commands.

I would expect that ST implement this once and for all in STM32_Programmer_CLI. That would reinforce the idea that all STM32 products are a coherent family rather than a bunch of separate product lines.

[LCE]

No script needed, just enter the "UID_BASE" address (here: 1FF80050, see the corresponding device / sub-family specific *.h file) and read a few bytes.

There's also further MCU info in the bottom right corner of the window.

 

 

[acapola]

good to know that this is possible through the GUI. I have nothing against scripting, actually it is preferred to be able to track a large pool of devices. My point was that ST tools should handle the differences within the STM32 family to let users focus on their application rather than implementing slightly different commands to talk to one STM32G or STM32U...

I will mark STOne-32's answer as the accepted one as it is the most scalable.