MCU Device ID same for STM32 H747XG, H747XI, H757XI MCUs

[justin11]

Hi,

I'm currently looking for a way to identify the MCU attahced to a common pcb used. The MCUs are from the H7 series and im geeting unexpected results, as in they all return the same id 0x450

I have tried looking at the DBGMCU->IDCODE, HAL_GetDEVID() and HAL_GetREVID() none provide a unique identifier for the MCU type.

I can confirm that if i look at the FLASHSIZE_BASE it is reporting the correct changes in flash size relevant to the MCU.

I've also looked at this in cubeProgrammer and get the same common device id across all models.

Is this to be expected, ie all reporting the same Device ID ? if so is there any way to identify the model of the MCU?

[AScha.3]

Hi,

if its same chip -- same ID . Just the pins/case and tested memory size might differ, or some peripheral disabled.

see rm:

+

+ maybe ...check a peripheral, that should be here, but not on other chip (enabled).

 

[TDK]

This can be done if there are hardware differences on each board. For example, if PA0 is tied to ground on one board, set PA0 as an input with pullup--if it's low, then you know it's grounded on that board. You can use hardware differences like that to determine which board it's on.

There's no software-only solution to differentiate between the various models you gave (unless flash size is different).

 

> Is this to be expected, ie all reporting the same Device ID ?

Per the reference manual, this is the expected behavior.

 

[justin11]

thats a real shame you can't do it from a built in register, thought thats what the point of a register like that would be for.

[Tesla DeLorean]

It's a common die used on multiple lead frames, the final tester programs the FLASH amount based on the test type / program  (test time budget related price stratification), and they disable things like DSIHOST and CRYP to reduce licensing costs and import/export issues. The common die allowing for the millions of dollars for the maskset to be amortized across multiple parts.

There might be some ways to unpack the UNIQUE ID for package type, you'd need to converse with an FAE

Your distributor could program OTP/OB as a value-add

"2 Kbytes (64 flash words) of user option bytes for user configuration"

[Tesla DeLorean]

You can detect the HASH/CRYP units via whether the clock enable is stuck-at-zero, or via bits in the CR or SR registers, similarly report zeros in MCU where functionality has been disabled.

@Pavel A. posted a test example

If you don't have a means to externally strap different PCB/BoM, perhaps use OTP during manufacturing or testing on the line.