STM32内部温度传感器原理、误差分析与校准实战

做嵌入式这些年，我一直觉得"芯片内部还能测温"是个被低估的功能。很多人把它当成玩具，觉得反正精度不行，不如外接一个传感器省心。但我把STM32的内部温度传感器认真跑了一遍之后发现：只要搞清楚它的原理和误差来源，这东西在板级保护、工况监控这些场景里非常能打，关键是别把它当精密温度计用。这篇是学习笔记的第二十四篇，我把从原理到实验、再到校准的完整过程整理出来，希望能帮大家少踩几个坑。

1. 为什么要在MCU里装温度计：价值边界先想清楚

先问一个问题：芯片为什么要知道自己热不热？答案很简单，半导体的很多参数都随温度变化，时钟漂移、ADC基准电压漂移、MOSFET载流子迁移率变化，全和结温有关。芯片内部放一个温度传感器，等于给芯片装了一支体温计，系统可以随时知道自己是不是处于过热边缘，以便降频、休眠、报警或者触发保护动作。

STM32内部温度传感器的本质并不神秘，它利用的是半导体PN结正向压降随温度变化的特性。温度升高，PN结压降近似线性下降。MCU内部把这个电压信号放大之后接到ADC输入端，再由ADC转换成数字量，固件里通过一条公式把数字量换算成温度值。整个过程不需要任何外部器件，一个引脚都不占，成本几乎为零，这是它最大的价值。

但它的价值边界也很清楚：它测的是芯片结温，不是环境温度，更不是被测物体的温度。封装内部的热量和外部空气温度之间隔着一层封装材料，加上芯片自身的功耗发热，结温通常比室温高出一截。如果想用它测量环境温度，那等于让一个发烧的人去报室温，方向就错了。

所以在动手之前，我建议先把用途定下来。我的实验目标是：第一，把数据手册上关于内部温度传感器的描述全部跑通，确认读到的ADC值和理论公式吻合；第二，分析误差来源，看看在什么条件下数据可信；第三，通过简单校准把读数修正到可用的程度，用来做芯片过热保护。范围不贪大，够用就好。

2. 原理拆解：从PN结电压到ADC数值的完整信号链路

2.1 传感器输出特性与ADC通道映射

要正确使用内部温度传感器，得先看它的电气特性。参考手册里通常会给出一条典型输出曲线：在25°C时输出参考电压约为1.43V，电压温度系数约为4.3mV/°C。也就是说，温度每升高1°C，输出电压下降约4.3mV；温度每降低1°C，输出电压上升约4.3mV。这个斜率不算大，温度变化100°C，电压才变化430mV左右，所以后级ADC的分辨率直接决定了温度分辨率。

以12位ADC、3.3V参考电压为例，每个LSB对应的电压约为3.3V/4095，约0.806mV，换算成温度就是0.806/4.3，约0.19°C。听起来分辨率还可以，但这是理想情况，实际噪声、参考电压波动、芯片个体差异会把这个分辨率吞掉一大截。

关于通道映射，不同型号差异比较大。以我手头这颗F1系列芯片为例，内部温度传感器是连接到ADC1的通道16，内部参考电压连接到通道17。如果你用的是其它系列，通道号可能完全不同，有的甚至不在ADC1上，所以第一步一定要去查自己型号的参考手册，不能照搬网上的代码。

2.2 使能开关、采样时间与参考电压

内部温度传感器不是上电就一直工作的，它有一个使能位，名字通常叫TSVREFE，含义是"温度传感器和内部参考电压使能"。这一位不置1的时候，传感器输出是断开的，ADC读不到有效值；置1之后，传感器开始上电，但输出电压需要一段时间才能稳定下来。如果你刚使能就立刻读ADC，读到的值会慢慢漂，这是正常现象，不是代码写错了。

再就是采样时间。温度传感器的输出阻抗比普通外部信号源高不少，ADC内部采样电容需要在采样阶段把电压充到接近信号源电压。如果采样时间太短，采样电容充不满，转换结果就会偏低。这里我直接照手册建议把采样周期调到最大档，稳定优先，反正温度信号变化很慢，不需要像采集波形那样追求高刷新率。

还有参考电压的问题。内部温度传感器的输出电压是绝对电压值，而ADC转换结果是相对的，它代表"输入电压占参考电压的比例"。如果你直接用3.3V去换算，但实际板子上参考电压只有3.28V，那么每个ADC数值对应的真实电压就变了。温度计算的第一步就应该用实际参考电压，而不是标称值。

2.3 出厂校准值和两点线性插值

现在的很多STM32型号在出厂时会做温度校准，把芯片放在两个已知温度下分别测一次ADC原始值，然后把这两个值存进芯片的校准寄存器区。你读传感器时，只要把当前ADC值和这两个校准值做线性插值，就能得到比典型公式更准的温度。

需要说明的是，并不是所有型号都有这个待遇。F1系列的大部分型号在手册里给的还是典型值，也就是V25和平均斜率，这种参数是"大概率落在附近"的值，不是逐颗芯片实测的结果。正因如此，同一批芯片在相同室温下读出来的温度可能差好几度。

我用的这颗芯片能读到出厂校准值，所以我做了两种换算方式对比：一种用典型值公式，另一种用两点线性插值公式。结果确实有差异，后者更贴近实际环境温度。如果你的芯片没有校准值，也不用慌，后面我会讲怎么用外部温度计手动校准，效果同样能接受。

3. 实验过程：CubeMX配置、代码和第一次读数

3.1 CubeMX里的配置要点

实验工程我用的是CubeMX生成，再往里面填业务代码。生成工程时有几个配置点要注意，漏一个后面都会浪费时间。

第一是ADC使能。我选择ADC1并开启温度传感器通道。在CubeMX的ADC配置界面里，会有温度传感器通道的复选框，勾上之后它会自动帮你处理一部分寄存器。另外要把ADC的扫描模式关掉，我只需要单通道单次转换，开启扫描反而会把规则序列搞复杂。

第二是采样时间。我在ADC参数里把采样周期拉到最大档，大约是239.5个ADC时钟周期。这样单个通道的转换时间会变长，但温度信号不需要高速采样，慢而稳是正确选择。

第三是ADC时钟。芯片的ADC时钟上限在参考手册里有明确限制，不要超过。如果系统时钟太高，就要在时钟树里给ADC加上合适的预分频。这个参数不设对，ADC转换结果可能整体偏离。

第四是串口。我需要把温度数据打印出来观察曲线，所以额外配置了一个串口，波特率设为115200，用于输出日志。串口和ADC互不干扰，两个外设并行工作起来很轻松。

3.2 核心代码：读取温度原始值

工程生成之后，我写了一个专门读取内部温度原始ADC值的函数。思路很清楚：确保温度传感器已经使能，把通道和采样时间配置好，触发一次转换，等EOC标志置位，再把数据寄存器读回来。

static uint16_t read_temp_adc(void) { volatile uint32_t timeout = 10000; /* 开启温度传感器和内部参考电压 */ ADC1->CR2 |= ADC_CR2_TSVREFE; /* 规则序列第1个通道选温度传感器，采样时间人为拉长 */ ADC1->SQR3 = 16; ADC1->SMPR2 |= (0x7UL << 0U); /* 软件触发一次转换 */ ADC1->CR2 |= ADC_CR2_EXTTRIG | ADC_CR2_SWSTART; /* 等待转换结束，加超时保护，避免死循环 */ while (!(ADC1->SR & ADC_SR_EOC)) { if (--timeout == 0) { break; } } return (uint16_t)ADC1->DR; }

这段代码用的是寄存器操作方式，不同系列的寄存器位定义略有差别，但整体思路一致。如果你用的是HAL库，对应的工作就是初始化一个ADC_ChannelConfTypeDef结构体，选择温度传感器通道，然后调用注入或规则转换接口。我不建议在这个功能上纠结库函数名，因为版本差异太大了，理解寄存器行为反而更通用。

3.3 第一次读数的过程和感受

代码下载之后，串口开始输出数据。我做的第一件事是连续打印原始ADC值，看看数值稳不稳定。刚上电那会儿，ADC值明显有一个爬升过程，大约过了两三分钟才基本稳定。这个现象有两层原因：一是芯片从冷启动到热平衡需要时间，二是传感器供电稳定也需要时间。所以正式采集数据之前，至少要等系统热起来，不能一上电就记录。

我还做了另一个测试：把芯片空载运行和跑一个满负荷的程序对比。满负荷时ADC值明显升高，换算出的温度能高出好几度。这说明内部传感器对芯片自身的功耗变化非常敏感，也是后面分析误差时必须考虑的因素。

4. 误差源分析：读到的温度为什么和室温对不上

4.1 自热效应：测的是结温不是室温

第一个"误差"其实不是误差，而是物理事实。芯片运行时，内部功耗会以热量的形式散发，芯片结温必然高于环境温度。芯片负载越重，结温和室温的差值越大。

实验数据很直观。室温26°C左右时，空载状态下芯片稳定后的温度读数是34°C左右，满负荷运行后飙升到接近47°C。很多人第一次跑通内部温度传感器后，看到读数比室温高就以为算法有问题，赶紧去改公式。实际上公式没错，错在把结温和环境温度画了等号。芯片封装内部的热量本来就散不出去，结温高于环境温度是必然的。

4.2 参考电压波动带来的读数偏移

再来看一个真正的系统误差：参考电压。温度换算公式里必须用到VREF，但不少开发板的3.3V并不是精确的3.300V。有的板子实测3.28V，有的甚至到3.45V。这个偏差对ADC的绝对电压计算影响很大。

举个例子，假设转换结果是1500，理论3.3V参考下对应电压约1.209V。如果实际参考电压是3.45V，那真实电压其实是3.45*1500/4095，约1.264V。相差55mV，换算成温度就是55/4.3，约12.8°C。看到没有，参考电压偏差5%就能带来十几度的误差，这比传感器本身的分散性还可怕。

所以数据类型上也有讲究：计算电压时如果只用整数除法，结果很容易被截断。我把ADC值转成浮点数再算，虽然MCU做浮点运算慢一点，但温度采集本身频率低，性能完全不是问题。

4.3 芯片个体差异和ADC偏移

哪怕参考电压很准，不同芯片之间也存在制造偏差。典型值公式里的V25和斜率是大量芯片的平均表现，具体到某一颗芯片，它的实际V25可能偏离典型值几十毫伏，斜率也可能有偏差。这就是为什么两颗芯片在相同条件下读出的温度能差3到5°C。如果系统对温度精度要求不高，这个偏差还能忍；如果要做比较严格的热保护阈值，就必须引入校准步骤。

4.4 采样噪声和数据处理

最后还有一个容易被忽略的误差源：数字噪声。MCU内部数字电路高速翻转，会在模拟信号上叠加毛刺。单次ADC转换的结果可能有几个LSB的跳动，换算成温度就是零点几度的抖动。解决的办法很简单：连续采集多次取平均。我这里做了16次采样，去掉一个最大值和一个最小值后求平均，读数立刻稳定很多。

5. 实测校准与修正：一两个点就能让数据变可靠

5.1 用外部温度计做两点校准

既然芯片内部传感器存在固定偏差，那最简单的办法就是拿一个可信的外部温度参考做两点校准。校准时不需要昂贵的恒温槽，抓住两个容易获得的温度点就够了。

第一个点用常温。我把数字温度计的探头贴在芯片外壳上，让系统空载运行到热平衡，记录下此刻外部温度计的读数和内部传感器的ADC值。因为芯片外壳温度和结温之间有热阻，直接拿外壳温度当结温不是百分之百准确，但对校准用途来说已经够了。

第二个点让芯片进入满负荷状态，让结温明显升高，再记录一组外部温度和ADC值。为了避免传感器输出非线性的影响，两个校准点尽量分布在目标测温范围的两端，比如一个30°C左右，一个50°C左右。

有了这两组数据，我就能算出一条针对当前芯片的校准直线。校准后的效果很直接：未校准时读数比参考温度高出6到8°C，校准之后偏差缩小到1°C以内。这不是把误差变没了，而是把芯片个体偏差和参考电压偏差一起用一条直线补偿掉了。

5.2 没有外部校准源时的修正技巧

如果你手头没有数字温度计，也有个土办法：利用人体体温。手掌长时间握住芯片封装，芯片温度会逐渐接近体温，大约36°C到37°C。用力握紧几分钟后，记录内部传感器的ADC值，然后假设真实温度是体温，就能估算出一个偏移量。这个办法精度不高，但用来判断传感器是不是严重偏离谱还是够用的。

另外可以用一个更贴近工程实际的思路：不关心绝对温度，只关心相对变化。给系统设置一个开机基线温度，之后每隔一段时间读取当前温度，如果比基线高出比如20°C，就认为芯片面临过热风险。这种处理方式绕开了绝对精度问题，而且特别适合做保护逻辑。

5.3 校准之后的实测数据对比

我把校准前后的数据放在一起做了个对比，能清楚看到修正效果。以下是在一次实验中记录到的值，校准后的结果是直接把当前ADC代入校准公式得到的。

从表格里能看出两个信息。第一，校准能显著拉近内部读数和外部参考值的距离；第二，满负荷时外部参考温度和内部读数之间的差值本来就更大，这是热阻造成的真实物理现象。校准公式利用了两个温度点的外部参考值，等于把热阻导致的系统偏差也一起补偿了一部分。

5.4 校准代码怎么组织

校准完成之后，我在固件里简单加了一组宏来保存校准参数。实测过程中发现，把校准参数放到一个独立结构体里，后续换芯片时只需要改结构体里的数值，不用动主流程代码，维护起来轻松很多。

typedef struct { float offset; /* 截距补偿，单位°C */ float k; /* 斜率系数，无量纲 */ } temp_cal_t; /* 校准参数由外部参考温度计实测得到，换芯片需要重新校准 */ static const temp_cal_t g_temp_cal = { .offset = -6.8f, .k = 0.92f, }; static float cal_temp(float raw_temp) { return raw_temp * g_temp_cal.k + g_temp_cal.offset; }

这个线性模型不算严谨，因为内部温度传感器的特性曲线并非绝对直线，但在窄温度范围内它的线性度足够好，完全够保护逻辑使用。如果你要求的温度范围很宽，那就需要读取出厂校准值或者用多点插值表，模型会复杂不少。

6. 内部温度传感器的适用场景与使用禁忌

6.1 适合做的工作

我实验做完之后，最大的体会是：内部温度传感器最适合做定性保护和趋势监控。

过热保护是首选场景。程序把当前结温和一个阈值比较，比如85°C，超过之后降低PWM占空比、关闭不必要的外设，甚至是进入低功耗模式。这类逻辑不要求温度绝对准确，只要求在安全阈值附近行为正确，内部传感器完全能胜任，而且不用增加任何BOM成本。

趋势监控也很好用。设备运行过程中每隔一段时间记录一次温度，保存成历史曲线，再对比当前温度和同期温度。如果温度异常爬升，大概率是散热风扇堵了、散热硅脂老化了，或者是负载异常。这类"看变化不看绝对值"的应用，内部传感器的精度短板并不致命。

还有一个场景：批量测试时的快速筛检。如果一批板子在上电后温度曲线明显偏离正常范围，很可能是芯片焊接有问题或者PCB散热设计有缺陷。这种对比性检测用内部传感器做非常方便，每个板子都能测，不需要额外接传感器。

6.2 不适合做的工作

和适用场景对应的是明确的禁区。第一，不要把它当环境温度计。结温和环境温度之间隔着封装热阻和芯片功耗，功耗一变，结温和室温的关系就变了。测环境温度，老老实实用NTC或数字温度传感器。

第二，不要用在需要高精度计量的场景。内部温度传感器经过校准后能到1°C左右的误差已经算不错，但冷链运输、医疗设备这些场景通常需要0.1°C级别的精度，内部传感器给不了。

第三，不要在剧烈温变场景下测量瞬态温度。芯片封装本身有热容，结温变化滞后于外部温度变化，想捕捉快速温度变化，传感器的放置位置和响应速度都不合适。

6.3 后续可以扩展的玩法

实验做完之后，我还留了几个可以扩展的方向。一个是把内部温度传感器和外部传感器配合使用：内部传感器负责结温保护，外部传感器负责环境温度采集，两路数据互相印证，系统对自身散热状态就有更完整的判断。

另一个是把温度数据接进实时任务里。比如在RTOS中开一个低优先级任务专门采温度，温度超过阈值时向高优先级任务发事件，触发保护动作。这样温度采样不阻塞主流程，保护响应也及时。

最后还可以做老化预测。记录长期运行中的温度变化趋势，配合运行时长统计，可以在芯片或电源模块彻底失效之前提前报警。这种玩法对数据模型有一定要求，但很值得尝试。

经过这一轮实验，我对内部温度传感器的定位有了更实在的认识：它不是一个精密的测量工具，但它是芯片自带的"体温计"，用对了地方，便宜又可靠。最后再分享一个小技巧：正式使用之前，先让板子在典型负载下跑一段，记录一个健康的温度基线，后面所有告警阈值都围绕这个基线来定，比查数据手册拍脑袋定阈值靠谱得多。