当前位置：首页 > news >正文

ESP32与STM32芯片唯一标识符(UID)与MAC地址获取全解析

news 2026/8/6 4:06:46

1. 项目概述：为什么我们需要芯片的唯一“身份证”？

在嵌入式开发中，尤其是在物联网（IoT）设备、智能硬件或者需要设备身份认证的场景里，我们经常会遇到一个看似简单却至关重要的需求：如何让设备证明“我就是我”？比如，一个基于ESP32的智能插座需要向云端服务器注册，服务器必须能唯一地识别它，防止被其他设备冒用；又或者，一个基于STM32的工业控制器，其固件授权需要绑定到具体的硬件上，确保软件不会被随意复制到其他设备上运行。这时候，芯片内置的唯一标识符（Unique ID, UID）和媒体访问控制地址（MAC Address）就成了设备的“身份证”和“网络身份证”。

这个项目标题“ESP32 | STM32获取芯片MCU唯一标识符、MAC”直指的就是这个核心需求。它不是一个复杂的算法实现，而是一项基础但极其重要的底层操作技能。对于ESP32这类高度集成的Wi-Fi/蓝牙SoC，以及STM32这类通用的微控制器，获取它们的唯一ID和MAC地址的方法、原理和注意事项各有不同。掌握这些方法，意味着你为设备赋予了独一无二的身份，这是实现设备管理、安全启动、固件加密、动态绑定等高级功能的第一步。很多新手开发者可能会在需要时才临时搜索代码片段，但往往忽略了背后的细节，比如ID的可靠性、读取方式对功耗的影响、在不同系列芯片上的兼容性等，导致后期出现难以排查的“灵异”问题。今天，我们就来彻底拆解这个主题，不仅告诉你“怎么拿”，更要说清楚“为什么这么拿”以及“拿了之后要注意什么”。

2. 核心概念解析：UID与MAC到底是什么？

在深入代码之前，我们必须先厘清几个核心概念。很多开发者对“唯一标识符”和“MAC地址”的理解是模糊的，甚至混为一谈，这为后续开发埋下了隐患。

2.1 芯片唯一标识符 (Chip Unique ID / UID)

芯片唯一标识符，通常是一串由芯片制造商在生产过程中一次性写入（熔断或固化）到芯片硅片上的只读数据。这个ID对于每一颗芯片都是全球唯一的（理论上），就像人的指纹。它的核心特性包括：

唯一性：这是其最重要的价值。制造商通过复杂的工艺确保在可预见的出货量内，两个芯片拥有相同ID的概率极低。
只读性：通常无法通过软件修改，存储在芯片的特定只读存储区域（如Flash的特定扇区、OTP区域等）。
非标准性：其长度、格式（十六进制、二进制）、存储位置和读取方式完全由芯片厂商定义，没有统一标准。ESP32的UID和STM32的UID就截然不同。
用途：主要用于硬件绑定、安全加密（作为加密算法的输入因子）、设备身份认证、生产追溯等。

注意：虽然称为“唯一”，但在极端罕见的情况下，理论上存在碰撞（重复）的可能。对于超高安全等级的应用，有时需要结合其他信息（如板载序列号）来构成更可靠的唯一身份。

2.2 媒体访问控制地址 (MAC Address)

MAC地址是一个用于在物理网络段中识别网络设备的地址。对于集成网络功能的芯片（如ESP32的Wi-Fi/蓝牙），MAC地址是其网络接口的“身份证”。它的特点是：

标准性：遵循IEEE 802标准，通常为48位（6字节）或64位（8字节，如EU1-64格式）。我们常见的是48位格式，如24:0A:C4:00:01:02。
可配置性：虽然芯片出厂时会烧录一个默认的MAC地址（通常基于厂商的组织唯一标识符OUI），但在许多情况下，软件可以对其进行重写或覆盖（尤其是在初始化网络协议栈时）。ESP32就允许开发者基于基础MAC地址进行自定义。
分层性：一个多网络接口的芯片（如ESP32同时有Wi-Fi Station, Wi-Fi SoftAP, Bluetooth）可能会有多个相关的MAC地址，它们通常由一个基础MAC地址衍生而来。
用途：用于局域网（LAN）内的设备寻址，是TCP/IP协议栈底层（数据链路层）通信的基础。

关键区别：UID是芯片的身份证，与网络功能无关，哪怕芯片不联网，UID也存在。MAC地址是网络接口的身份证，只有具备网络功能的芯片或外设才有。ESP32两者皆有，而一个没有网络外设的STM32F103芯片只有UID，没有MAC地址（除非你外接了以太网或Wi-Fi模块，那MAC地址属于那个模块）。

3. ESP32篇：获取UID与MAC的实战与内幕

ESP32作为乐鑫推出的明星级物联网芯片，其系统高度集成，乐鑫的ESP-IDF框架为我们提供了非常便捷的API来获取这些信息。但便捷的背后，也有很多值得深究的细节。

3.1 获取芯片唯一标识符 (ESP32 UID)

ESP32的UID通常指的是其MAC地址本身（对于芯片身份而言），但更精确的“唯一”标识，可以通过读取eFuse中的特定字段获得。eFuse是一次性可编程存储器，芯片出厂后某些位被熔断以存储信息。

方法一：获取基础MAC地址作为芯片ID这是最常用、最直接的方式。ESP32的48位基础MAC地址在出厂时被烧录到eFuse的BLK0（EFUSE_BLK0）中，对于大多数应用，这个地址足以作为芯片的唯一标识。

#include “esp_system.h” #include “esp_mac.h” void print_chip_id_via_mac() { uint8_t base_mac[6]; // 存储6字节MAC地址 esp_err_t ret = esp_efuse_mac_get_default(base_mac); if (ret == ESP_OK) { printf(“芯片基础MAC地址 (可作为UID): “); for (int i = 0; i < 6; i++) { printf(“%02x”, base_mac[i]); if (i < 5) printf(“:”); } printf(“\n”); } else { printf(“获取MAC地址失败: %s\n”, esp_err_to_name(ret)); } }

为什么是esp_efuse_mac_get_default？这个API直接读取eFuse中存储的原始出厂MAC。它比esp_read_mac更底层，esp_read_mac函数会考虑软件是否通过esp_base_mac_addr_set()设置过自定义MAC，返回的是最终使用的MAC。对于需要硬件唯一性的场景，直接读eFuse更可靠。

方法二：读取eFuse中的其他唯一信息对于安全性要求更高的场景，可以组合多个eFuse值来生成一个更长的唯一ID。例如，读取EFUSE_BLK1（如果可用）或结合MAC与ESP32_CHIP_ID（芯片版本信息）。

#include “esp_chip_info.h” void print_chip_info() { esp_chip_info_t chip_info; esp_chip_info(&chip_info); printf(“芯片型号: ESP32-%s, 核心数: %d, 版本: %d\n”, (chip_info.model == CHIP_ESP32) ? “D0WD” : “Unknown”, // 常见型号 chip_info.cores, chip_info.revision); // 芯片版本revision也可以作为唯一性的一部分参考 }

实操心得：

eFuse读取的功耗与速度：频繁读取eFuse并不是零成本操作。它比读普通内存慢，且会消耗少量能量。虽然对于单次初始化可以忽略不计，但切忌在循环中频繁调用。
MAC地址的格式：获取到的MAC是6字节的二进制数组。如果你需要将其转化为字符串用于HTTP请求头、文件名或数据库存储，建议格式化为十六进制字符串且去除冒号，例如240ac4000102。这样更紧凑，且避免了冒号在某些场景下（如URL、文件名）可能带来的转义问题。
双核情况：获取UID/MAC的操作，建议放在app_main函数初始化阶段，且无需考虑多核任务同步问题，因为这些数据是只读的。

3.2 获取与操作网络MAC地址

ESP32可以有多个MAC地址，理解其衍生关系至关重要。

1. 获取当前使用的各种MAC地址

#include “esp_mac.h” void print_all_macs() { uint8_t mac[6]; // 1. Wi-Fi Station MAC (客户端模式) esp_read_mac(mac, ESP_MAC_WIFI_STA); printf(“Wi-Fi Station MAC: “); print_mac(mac); // 2. Wi-Fi SoftAP MAC (接入点模式) esp_read_mac(mac, ESP_MAC_WIFI_SOFTAP); printf(“Wi-Fi SoftAP MAC: “); print_mac(mac); // 3. Bluetooth MAC esp_read_mac(mac, ESP_MAC_BT); printf(“Bluetooth MAC: “); print_mac(mac); // 4. Ethernet MAC (如果使能了以太网) // esp_read_mac(mac, ESP_MAC_ETH); } void print_mac(uint8_t *mac) { for (int i = 0; i < 6; i++) { printf(“%02x”, mac[i]); if (i < 5) printf(“:”); } printf(“\n”); }

2. MAC地址的衍生规则ESP-IDF有一个内部的MAC地址衍生规则。基础MAC地址（从eFuse读取）被用作“种子”。其他MAC地址在此基础上计算得出，通常是给基础MAC地址的最后一个字节加上一个偏移量。例如：

Wi-Fi Station MAC = 基础MAC
Wi-Fi SoftAP MAC = 基础MAC，最后一位 +1
Bluetooth MAC = 基础MAC，最后一位 +2

这样做确保了同一芯片上的不同网络接口拥有唯一且相关的MAC地址。

3. 如何设置自定义MAC地址？有时，出于产品管理或替换损坏芯片的需求，我们希望覆盖出厂MAC。

#include “esp_wifi.h” void set_custom_wifi_mac() { // 定义一个自定义MAC地址（务必确保在局域网内唯一！） uint8_t custom_mac[6] = {0x24, 0x0A, 0xC4, 0x12, 0x34, 0x56}; esp_err_t ret = esp_wifi_set_mac(WIFI_IF_STA, custom_mac); if (ret != ESP_OK) { printf(“设置STA MAC失败: %s\n”, esp_err_to_name(ret)); } // 注意：需要在wifi_init()之后，wifi_start()之前调用 }

重要警告：自定义MAC地址必须谨慎！必须确保你设置的地址不会与网络中其他设备冲突。滥用或随机设置可能导致网络混乱。最佳实践是，从你拥有的合法OUI地址段中进行分配，或者使用基于芯片UID通过哈希算法生成的“伪随机”地址。

4. STM32篇：深入UID读取与实战应用

STM32的UID系统与ESP32完全不同。它没有集成的网络功能，因此焦点完全集中在芯片唯一标识符上。STM32的UID存放在芯片内部Flash存储器的特定系统存储区域，通过内存映射的方式访问。

4.1 标准方法：通过参考手册与内存映射读取

这是最通用、最可靠的方法。你需要查阅对应STM32系列（如F1, F4, H7等）的《参考手册》，找到“Unique device ID register”章节。UID的地址通常是固定的，例如在STM32F1系列中，UID起始地址是0x1FFFF7E8。

通用读取函数示例 (基于STM32 HAL库)：

#include “main.h” // 包含你的芯片头文件，如stm32f1xx_hal.h void print_stm32_uid() { // 1. 定义UID地址。以下地址以STM32F103C8T6为例，其他芯片务必查手册！ #define UID_BASE_ADDRESS 0x1FFFF7E8UL #define UID_SIZE_BYTES 12 // STM32F1 UID为96位，12字节 // 2. 将地址转换为指针。使用`volatile`防止编译器优化，使用`const`表明只读。 volatile const uint8_t *uid_ptr = (volatile const uint8_t *)UID_BASE_ADDRESS; printf(“STM32 Unique ID (96-bit): “); // 3. 读取并打印。注意STM32是小端字节序(LSB在前)。 // 但UID的“唯一性”是整个数据块，我们通常按字节顺序读取即可。 for (int i = 0; i < UID_SIZE_BYTES; i++) { printf(“%02X”, uid_ptr[i]); // 按地址递增读取 // 如果你想按16位或32位读取，需要注意对齐和字节序。 // 例如： uint32_t uid_part = *(volatile const uint32_t*)(UID_BASE_ADDRESS + i*4); } printf(“\n”); // 4. (可选) 将UID转换为一个更方便使用的整数或字符串 // 例如，取后64位作为一个长整型ID (假设你的应用不需要完整的96位) uint64_t short_uid = 0; for (int i = UID_SIZE_BYTES - 8; i < UID_SIZE_BYTES; i++) { short_uid = (short_uid << 8) | uid_ptr[i]; // 组合字节 } printf(“截取的后64位UID: %llX\n”, short_uid); }

为什么使用volatile const指针？

volatile：告诉编译器，这个指针指向的内容可能被硬件改变（虽然UID不会变），禁止编译器对这个区域的读取操作进行优化（如缓存读取值、省略“冗余”读取）。对于内存映射的硬件寄存器，必须使用volatile。
const：表明我们不会去写入，符合UID只读的特性，同时也能让编译器进行一些优化。

4.2 使用STM32CubeIDE/HAL库的便捷方法

对于使用STM32CubeMX生成代码的项目，HAL库提供了一个更便携的宏来获取UID，但本质上它还是指向了那个固定的地址。

// 在main.c中，通常已经由CubeMX定义了芯片相关的头文件 #ifdef STM32F1 #define UID_BASE UID_BASE_F1 // 具体宏名需查看芯片头文件 #endif // 更通用的方法是直接使用HAL库的标识符（如果可用） // 有些系列的HAL库定义了 UID_BASE，但并非所有。 // 最保险的做法仍然是查阅你所用芯片系列的HAL库头文件，例如： // 在 stm32f1xx_hal.h 中搜索 “UID”

实操心得：

地址是硬编码的：UID地址是芯片设计时固定的，不同STM32系列（甚至同系列不同容量型号）地址可能不同。F1、F4、L4、H7的UID地址都不一样。每次换芯片型号，第一件事就是查《参考手册》确认UID地址！这是最容易出错的地方。
UID长度不统一：STM32F1是96位（12字节），STM32F4是96位，而有些系列可能是128位。代码中的UID_SIZE_BYTES需要根据手册调整。
字节序问题：虽然我们按字节读取最安全，但如果你需要将UID作为一个整体（如32位整数数组）进行哈希或比较，需要注意STM32是小端架构。例如，地址0x1FFFF7E8存储的是UID的最低有效字节（LSB）。在将UID发送到网络（通常是大端序）或与其他大端系统比较时，可能需要转换字节序。
UID的稳定性：STM32的UID在芯片复位、掉电后保持不变，且无法被用户程序擦写。它是硬件级别的标识。

4.3 STM32 UID的典型应用场景

固件加密与授权：

// 在固件中预置一个加密密钥（或密钥种子），该密钥与UID绑定 uint64_t device_uid = get_shortened_uid(); // 获取缩短的UID uint32_t secret_key = calculate_key(device_uid, master_secret); // 在运行时，验证通过UID计算出的密钥是否与预期匹配，不匹配则限制功能。

生成设备序列号：

char serial_num[25]; snprintf(serial_num, sizeof(serial_num), “PROD-%012llX”, get_shortened_uid()); // 生成如 “PROD-240AC4123456” 的序列号，用于贴标、扫码录入系统。

通信加密的盐值：在设备与服务器首次握手时，将UID作为盐值（Salt）参与密钥协商，增加通信的唯一性和安全性。

5. 常见问题与深度排查指南

在实际项目中，获取UID/MAC看似简单，却可能遇到各种意想不到的问题。下面是我从多个项目中总结出的“避坑”清单。

5.1 ESP32典型问题

问题1：获取到的MAC地址全是0xFF或0x00。

可能原因：eFuse读取错误，或者芯片的eFuse区域确实未被正确编程（某些早期工程样片或非正规渠道芯片）。
排查步骤：
1. 使用espefuse.py工具（ESP-IDF自带）连接芯片，查看eFuse摘要：espefuse.py -p PORT summary。检查MAC字段是否正常。
2. 确认使用的API是否正确。尝试使用esp_efuse_mac_get_default和esp_read_mac进行对比。
3. 如果eFuse中MAC确实为空，ESP-IDF在初始化网络时会使用一个软件生成的随机MAC。但这不能作为硬件唯一ID使用。
解决方案：联系芯片供应商。对于量产产品，务必在采购时确认芯片eFuse已编程。

问题2：Wi-Fi和蓝牙的MAC地址冲突，导致连接不稳定。

可能原因：自定义MAC地址设置不当，或者基础MAC衍生规则被破坏，导致两个接口MAC地址相同。
排查步骤：
1. 在初始化Wi-Fi和蓝牙之前，分别打印它们的MAC地址进行比对。
2. 检查代码中是否在esp_wifi_set_mac或esp_bluedroid_init等函数中设置了冲突的地址。
解决方案：遵循ESP-IDF的MAC地址衍生规则。如果需要自定义，确保为Station、SoftAP、BT分别设置唯一且符合OUI规范的地址。

问题3：UID/MAC在深度睡眠后“变化”了。

可能原因：这不是UID/MAC变了，而是你的程序在深度睡眠唤醒后重新初始化，可能因为代码逻辑问题，读取到了一个缓存值或错误地址。
排查步骤：在深度睡眠唤醒后的初始化函数中，加入打印UID/MAC的日志，与睡眠前对比。确保读取函数在唤醒后能被正确执行，且依赖的硬件（如eFuse控制器）已就绪。
解决方案：将UID/MAC读取操作放在唤醒后稳定的初始化阶段，避免在RTC内存中存储指向易失数据的指针。

5.2 STM32典型问题

问题1：读取UID导致硬件错误（HardFault）。

可能原因：
1. 地址错误：使用了错误的UID基地址，访问了非法内存区域。
2. 对齐错误：试图以32位方式读取一个非4字节对齐的地址（虽然UID地址通常是对齐的，但误操作可能导致）。
3. 内存保护：在某些高安全系列（如TrustZone）或配置了MPU（内存保护单元）的芯片上，对系统存储区域的访问可能被禁止。
排查步骤：
1. 核对《参考手册》：这是第一步，也是最重要的一步。
2. 检查指针类型转换是否正确。
3. 在调试器中，单步执行到读取UID的那行代码，观察指针值是否与手册一致。
4. 尝试先以8位（字节）方式读取第一个字节，看是否成功。
解决方案：修正地址；确保以字节访问或对齐访问；检查并配置MPU或安全状态，允许对系统存储区的读取。

问题2：不同批次的芯片，用同样的代码读出的UID格式感觉不一样。

可能原因：你的代码对UID的“解释”方式不一致。例如，有的代码将UID当作一个16进制字符串打印，有的将其当作一个整数数组进行哈希。如果打印时格式控制符不对，或者组合字节时顺序（端序）处理不一致，就会导致表象不同。
排查步骤：统一使用最原始的字节数组打印方式进行比较。写一个简单的测试固件，只做一件事：按字节顺序打印UID。烧录到不同批次的芯片上运行，对比输出的原始字节流。
解决方案：在项目初期就确定UID的使用规范。例如：“本项目统一将UID视为一个12字节的大端序数组进行处理和存储”。所有涉及UID的代码（读取、发送、比较、哈希）都遵循这个规范。

问题3：UID用于加密种子，但设备丢失后无法恢复。

可能原因：这是产品设计逻辑问题，而非技术问题。将UID作为加密的唯一因子，意味着固件和芯片必须一一对应。如果芯片物理损坏，即使你有备份的固件，也无法运行在新的芯片上。
解决方案（分级）：
- 消费级：接受此限制。设备损坏即报废。在用户协议中说明。
- 企业级/工业级：实现一个授权服务器。设备首次上线时，将UID上报服务器，服务器返回一个激活码或令牌。这样，更换芯片后，新设备可以重新联系服务器获取授权。UID在这里用作设备身份证明，而非加密密钥本身。

5.3 通用最佳实践与安全考量

不要直接暴露原始UID/MAC：尤其是在网络通信或日志中。攻击者可能利用此信息进行设备克隆或追踪。建议对原始ID进行哈希（如SHA-256）后再使用，哈希值即为你的“设备指纹”。
本地存储备份：对于关键应用，可以在设备首次启动时，读取UID/MAC，计算出一个派生ID，并将其存储到非易失存储器（如EEPROM、Flash的某个分区）中。这样，即使主芯片的UID读取电路出现极端问题，也有一个备份标识符可用。
生产测试环节验证：在产品量产烧录和测试工位上，增加一个自动读取并记录UID/MAC的步骤。将读取到的ID与产品序列号绑定，录入数据库。这为后续的质保、追踪和售后服务提供了数据基础。
考虑UID的耗尽问题：虽然概率极低，但从理论上看，任何唯一标识符系统都有耗尽的可能。对于计划出货量巨大的产品（数亿台），需要了解芯片厂商的UID分配策略和容量，评估风险。

获取MCU的唯一标识符，就像为每一个智能设备办理了一张终身身份证。这张身份证是连接物理世界与数字世界的信任锚点。无论是ESP32还是STM32，理解其原理、掌握其方法、规避其陷阱，是每一位嵌入式开发者构建可靠、安全、可管理产品的基础能力。希望这篇详尽的拆解，能让你下次在调用那几行读取函数时，心中更有底气。

查看全文

http://www.cnnetsun.cn/news/3861608.html