This documentation covers a STM32 Nucleo-H753ZI tutorial project that reads the MCU's factory-programmed 96-bit unique device ID and prints it over the standard debug USART. It is a from-scratch revision of the site's older STM32 Unique ID tutorial, simplified and modernized.

Project Overview

The firmware demonstrates:

STM32H753ZI peripheral setup generated by STM32CubeMX
Reading the 96-bit unique ID via HAL_GetUIDw0()/HAL_GetUIDw1()/ HAL_GetUIDw2() – an internal MCU register present on every STM32 family, requiring no external circuitry
Reading the rest of ST's "device electronic signature": DBGMCU->IDCODE (device/revision identification) and FLASHSIZE_BASE (flash capacity)
Printing all of it over USART1 (PA9 TX / PA10 RX) via an external FTDI USB-to-serial adapter, the site's standard debug UART setup

Device ID vs. Revision ID vs. board

DBGMCU->IDCODE is entirely independent of which board the chip is mounted on – the same STM32H753ZI reports the identical value whether it's on a Nucleo-H753ZI, a custom PCB, or any other carrier. But its two halves don't carry the same guarantee as each other:

DEV_ID identifies the part/die family and is identical for every STM32H753ZI ever manufactured, full stop.
REV_ID identifies the silicon revision (stepping) – it can differ between manufacturing batches of the same part number if ST ever revises the silicon (e.g. to fix an erratum), so two STM32H753ZI chips can legitimately report the same DEV_ID but a different REV_ID.

This is separate from the UID discussed above either way: the UID is unique per physical chip; DEV_ID/REV_ID describe the part and its silicon revision, not the individual chip.

Practical use: picking a board's role from its UID

Reading a UID is only half the story – the useful part is what you do with it. F439_CPP_TX-RX_LoRa_Project_01 (a two-board LoRa link) runs the IDENTICAL compiled firmware image on both the transmitter and the receiver: at boot, each board reads its own UID and compares it against two hardcoded, already-known UID sets to decide which role to play:

if (uid[0]==RX_UID0 && uid[1]==RX_UID1 && uid[2]==RX_UID2) {
    role = ROLE_RX;
} else if (uid[0]==TX_UID0 && uid[1]==TX_UID1 && uid[2]==TX_UID2) {
    role = ROLE_TX;
}

No jumpers, no DIP switches, no separate "TX build" and "RX build" to keep in sync – one firmware image that already knows, from hardware-guaranteed identity, which board it's running on. The tradeoff: both UIDs have to be known ahead of time. The compile-time alternative is a #ifdef ROLE_TX / #ifdef ROLE_RX switch instead – that sidesteps ever needing to know a UID in advance, but brings back the two-separate-builds problem this technique avoids.

Relationship to the older tutorial

The original STM32 Unique ID tutorial (F103_C_Device_Electronic_Signature, 2024) additionally ran the UID through a third-party 32-bit hash function (Hash32Len5to12() from a borrowed stm32_uidhash.h) and never printed any result over serial at all. This revision drops the unnecessary hash step entirely – direct comparison of the raw UID words is sufficient, as shown above – and adds real USART output, which the original never had.

Board independence

The UID-reading logic is identical on every STM32 board regardless of family or package – HAL_GetUIDw0/1/2() is a fixed internal register read with no external wiring involved. The Nucleo-H753ZI used here is purely a build convenience (reusing an already-proven USART1/FTDI setup), not a requirement.

Architectural Direction

This project's documentation is intentionally a single mainpage – a project this small doesn't need the multi-page/@defgroup layered structure used by larger projects.