DRAM刷新机制与参数详解：从tREFI到自刷新，一文读懂

记得早年间第一次被领导按着头去查DDR初始化代码里的refresh相关寄存器时，我满脑子都是“这不就是定时给电容充电吗，有什么好查的”。结果板子在高温房里跑了一个小时，随机出现位翻转，排查了整整两天才把问题定位到tREFI配置和温度特性的匹配上。从那以后我对DRAM刷新这件事就不敢再“想当然”了。

DRAM刷新（refresh）确实是基础中的基础，但越基础的东西反而越容易被忽略。很多做嵌入式或者硬件设计的同学，可能知道要配tREFI、tRFC，但真要问一句“这个值是怎么来的”“温度变了会有什么影响”“为什么自刷新能省电”，往往就说不清了。这篇作为系列基础小知识的第三篇，就把贴吧、群里大家最常问的DRAM刷新问题好好归归类，从原理到参数再到故障排查，争取一次讲透。

先给还没接触过这块的同学一句话概括：DRAM靠电容上的电荷保存数据，而电容会漏电，所以必须定期给它们“续命”，这个动作就叫刷新。下面我们就从“为什么会漏电”开始，一步步拆开来看。

1. 为什么要刷新：电容漏电是根本原因

1.1 一个存储单元只有“一个晶体管加一个电容”

DRAM的存储单元结构极其简洁，每个bit就是一个MOS管加一个电容，业界叫1T1C。晶体管负责开关读写通道，电容负责用有没有电荷来代表0和1。你可以把它想象成无数个微型水桶：有水代表逻辑1，没水代表逻辑0。

问题就出在这个“水桶”上。DRAM里用的电容不是理想的储能元件，它存在漏电流路径，电荷会随着时间慢慢流失。这个漏电过程不是“瞬间”，但在纳米尺度、微安级别的漏电流下，几毫秒到几十毫秒内，电荷量就足以衰减到无法分辨0和1的程度。

所以DRAM不能像SRAM那样上电之后一劳永逸，它必须赶在电荷衰减到临界值之前，把数据读出来、放大、再写回去，这就是refresh的基本动作。

1.2 从“漏水的水桶”到“数据丢失”的推演

这里有个非常容易混淆的点：很多人以为refresh是“重新写一遍”，其实标准做法是“读出来再写回去”，而且这个过程对软件是透明的。更准确地说，现代DRAM的刷新操作是由内存控制器或者DRAM内部状态机负责的，CPU和操作系统感知不到。

推演一下整个过程：

1. 电容初始充满电荷，存储逻辑1。
2. 时间推移，漏电流让电荷减少。
3. 如果不做任何干预，经过一个数据保留时间（retention time），电容上电荷量掉到无法被灵敏放大器正确判读的门限以下。
4. 这时候哪怕只是正常读一次，读出来的可能已经变成0，数据就永久丢了。

数据保留时间通常在几十毫秒到几百毫秒之间，工业界标准做法是保证在标准工作温度下，所有存储单元至少能撑过规定的刷新周期，典型值是64ms（消费级DDR4/DDR3标准）。64ms听起来不长，但对现代内存控制器来说足够从容，因为刷新是按行推进的，不需要在同一瞬间照顾所有电容。

1.3 温升与漏电的恶性循环

温度对漏电流的影响是指数级的。JEDEC标准中，标准刷新率（比如64ms周期）是基于正常工作温度范围的，通常是0到85摄氏度的结温范围。超过这个温度，漏电速度会明显加快，数据保留时间随之缩短。

实测中我最常见的现象是：常温下跑压力测试一切正常，到了高温环境或者机箱散热不良时，开始出现偶发性的bit flip。这种问题最难查，因为看起来像逻辑bug，实际上就是refresh rate跟不上高温下的漏电速度。

所以在选型阶段，一定要确认芯片的刷新特性标称值，尤其是工业级、车规级产品，它们通常支持温度补偿刷新（Thermal Compensated Refresh，TCR），也就是芯片内部感知温度变化后自动缩短刷新间隔。这种机制在消费级内存上不一定完整支持。

2. 刷新到底是怎么执行的：机制与命令

2.1 三种经典刷新命令，你至少要知道名字

DRAM发展到现在，刷新机制经过多轮演进，命令接口上主要出现过三种：

• RAS Only Refresh（ROR）：最古老的方式，通过拉低RAS、保持CAS为高来触发行刷新。这在SDRAM之前的老异步DRAM上常见，现在已经很少单独使用了。
• CAS Before RAS Refresh（CBR）：先拉低CAS再拉低RAS，触发器进入刷新态。它比ROR更高效，不需要外部提供行地址，刷新行地址由内部计数器自动产生。
• Auto Refresh（自动刷新）：SDRAM及之后的DDR世代的标准操作。内存控制器直接发出REF命令，DRAM内部自动完成一行或多行的刷新，外部不需要关心具体刷新哪一行。

现在的DDR4、DDR5、LPDDR系列基本都用Auto Refresh为主，搭配Self Refresh（自刷新）实现低功耗场景。

2.2 刷新命令的动作拆解：行激活、预充电与内部计数器

以Auto Refresh为例，一次刷新动作几乎就是一次“隐形的行访问”：

1. 内存控制器发出REF命令。
2. DRAM内部地址计数器把当前要刷新的行地址送到行译码器。
3. 字线被激活，这一行的所有存储单元的电荷被送到位线上，经过灵敏放大器读出并放大。
4. 灵敏放大器把放大后的数据写回存储电容，等于给这一整行“充满了电”。
5. 字线关闭，执行预充电（precharge），为下一次刷新或正常读写做好准备。
6. 内部刷新计数器自增，指向下一行。

每一步都对应真实电路行为，所以刷新并不是瞬间完成的，它需要占用一段时间，这就是tRFC的来源。

这里特别要提醒一句：刷新是针对“行”的。内存控制器只需要知道总行数和刷新周期，不需要为每个bit单独操心。这也是为什么刷新操作对软件是透明的——你哪怕只是一个单字节的嵌入式系统，也得完成全阵列的行刷新，因为这是物理规律决定的。

2.3 自动刷新与自刷新的分工

Auto Refresh和Self Refresh是两套运作逻辑：

Auto Refresh是正常工作时使用的刷新方式，由内存控制器主动发起，CKE引脚保持高电平，系统时钟正常运行。它的优点是可以精确控制刷新时机，缺点是内存控制器要操不少心。

Self Refresh则用于系统休眠、待机等低功耗场景。这时候CKE被拉低，DRAM内部启动自己的振荡器和定时器，按内部节奏自发完成刷新，外部时钟甚至可以停掉。这样既保住了数据，又省下了时钟翻转和接口电路的大量功耗。

从嵌入式开发者的角度看，如果你的产品有sleep模式，并且sleep期间需要保留内存数据，那一定要确认进入Self Refresh的时序是否正确。很多低功耗项目踩坑都踩在“睡下去容易醒来难”上——CKE低下去之后，唤醒时的退出时序不对，轻则数据损坏，重则总线锁死。

3. 刷新参数怎么算：从tREFI到tRFC

3.1 一个公式理解tREFI与刷新率的关系

JEDEC标准里，DRAM的刷新参数核心是两组：刷新周期（Refresh Interval）和单次刷新操作耗时（Refresh Cycle Time）。

以DDR4标准颗粒为例：

• 全阵列刷新周期：64ms（标准温度），即保证在这个时间内所有行至少被刷新一次。
• 总行数：常见为8192行（8K refresh）。
• 刷新间隔的均值tREFI = 64ms / 8192 = 7.8125μs。

也就是说，内存控制器平均每7.8μs就得发起一次刷新命令。这个时间不是随意取的，它是“总预留时间 ÷ 总行数”得到的工程折中。如果行数变成16K，tREFI就要减半，刷新频率翻倍。

tRFC则是一次刷新命令从发出到完成所需的时间，DDR4颗粒常见的tRFC在260ns到350ns之间，具体看颗粒密度和工艺制程。密度越大，单次刷新涉及的行越多，tRFC越长。

3.2 为什么不是所有时刻都在刷新：脉冲式刷新

需要注意，7.8μs是平均间隔，实际内存控制器不会机械地每隔7.8μs发出一次REF。它会把刷新请求聚合处理，有时候把几次刷新合并成一批，在总时间窗口内完成即可。

这个策略叫“pulled-in”或“spread refresh”，目的是减少刷新对正常读写带宽的冲击。如果严格按照每个tREFI点刷一次，那些时间段内恰好发生密集读写请求时，总线冲突会非常严重。

所以实际系统中，内存控制器里有一套刷新仲裁逻辑：它维护一个刷新计时器，在tREFI窗口内灵活选择发起刷新的时机，甚至会提前累计刷新请求，等到总线空闲或者命令队列允许时批量执行。这个机制对性能影响很大，也是各家IP性能差异的隐藏原因之一。

3.3 温度补偿刷新是怎么工作的

前文提到，高温下漏电加快，需要缩短刷新周期。JEDEC标准定义了多种刷新周期档位：

• 标准模式：全阵列周期64ms，适用于0-85℃。
• 高温扩展模式：全阵列周期32ms，适用于85-95℃。
• 某些车规级颗粒还支持95℃以上的进一步缩短。

实现温度补偿刷新的常见做法是：DRAM芯片内部带温度传感器，输出温度码流，内存控制器读取后动态调整tREFI。比如温度超过阈值，就把tREFI从7.8μs调整到3.9μs。

如果你在做方案选型，需要特别确认芯片是否支持温度补偿刷新。有些低成本颗粒为了节省片上温度传感器，只支持固定刷新率，必须按最高工作温度对应的最短刷新周期来跑。这样虽然稳妥，但功耗会白白增加，因为常温下也在用高温档的高频刷新。

3.4 一个实际计算的例子

假设一颗DDR4颗粒，配置如下：

• 全阵列刷新周期64ms
• 总刷新行数8192
• tRFC 260ns
• tREFI 7.8125μs

那么在1秒内，STS名义上的刷新次数 = 1000ms / 64ms × 8192 = 128000次，但用tREFI直接算也会得到接近127988次，基本一致。而每次刷新占用260ns，意味着每秒钟有128000 × 260ns = 33.28ms花在刷新上。如果内存带宽利用率已经很高，这额外的33ms就会造成不小的性能损失。

这个数字看着不大，但在高带宽、低延迟场景下，每多1%的总线占用都可能引发连锁的延迟抖动。设计高性能系统时，这33ms是会直接计入你的延迟预算的。

4. 刷新对性能与功耗的影响：看不见的“隐形杀手”

4.1 刷新为什么会卡顿：刷新惩罚

刷新期间，DRAM的bank往往处于预充电或激活状态中，无法响应正常的读写请求。如果某一次刷新恰好落在关键路径上，CPU的一条load指令可能就要多等几百纳秒。内存控制器一般会尝试通过刷新调度来错开峰值，但遇到极端密集的访问模式，仍然不可避免地出现延迟尖峰。

这在实际调优中表现得非常明显。用AIDA64这类工具跑内存延迟测试时，你偶尔会看到几个异常高的延迟点，多半就是刷新撞上了访问请求。排队等待刷新完成后，延迟从几十纳秒直接跳到几百纳秒。

应对刷新惩罚的常见手段有：

• 增大内存控制器的命令队列深度，让刷新的等待时间被后续命令掩盖。
• 采用“刷新区间划分”，把刷新任务拆成小块，分散在多个tREFI窗口中，而不是一次性刷新多行。
• 使用伪通道（pseudo channel）或rank交错，让一个rank在刷新时另一个rank继续响应请求。

4.2 自刷新的功耗优势是怎么省出来的

自刷新之所以省电，根本原因在于它可以关闭外部时钟和大部分接口电路。DRAM内部只保留一个低频振荡器、刷新计数器和必要的灵敏放大器，其他高速逻辑全部进入待机状态。

LPDDR系列在低功耗场景下的Self Refresh功耗可以降到普通Active功耗的几十分之一。这也是手机、可穿戴设备、物联网设备在睡眠时能保持内存数据不丢的关键。

不过Self Refresh也有它的代价：因为外部时钟停了，退出Self Refresh时需要重新锁定时钟，延时可能达到几个微秒，甚至更长。如果你的产品要求“毫秒级快速唤醒”，这里就需要权衡：是保持Auto Refresh花更多静态功耗，还是进入Self Refresh牺牲唤醒时间。

4.3 内存控制器刷新调度的策略维度

现代内存控制器对刷新调度的优化远不止“定期发命令”这么简单。我见过的高端控制器至少会考虑三个维度：

• 时序窗口：根据tREFI、tRFC、tRAS等参数寻找最优的命令插入时机。
• bank/rank状态：优先在bank空闲时插入刷新，避免打断正在进行的读写操作。
• 服务质量（QoS）：为高优先级请求预留带宽，刷新尽量让路，但又要保证不超时。

这就像红绿灯配时，既要保证车辆（读写请求）顺畅通过，又不能一直不给行人（刷新请求）放行。配得好的控制器能把刷新对性能的影响压到很低，配得粗暴的可能让整体性能掉好几个百分点。

5. 常见问题与排查技巧实录

5.1 刷新相关故障现象速查表

下面的表格是我这些年排查过程中整理出来的，看到类似现象时可以按图索骥：

5.2 一次真实的高温排查实录

之前帮一个做边缘网关的朋友排查过一个典型问题。设备在空调房里一切正常，搬到户外阳光直射环境后开始频繁报内存ECC错误。一开始都怀疑是静电或者电源问题，后来把温度的权重调上来才恍然大悟。

排查步骤基本是这样：

1. 先确认内存芯片表面温度，用热电偶实测有83℃，接近85℃的临界点。
2. 查看颗粒型号的datasheet，确认它是标准刷新率产品，不支持TCR自动增强。
3. 查看固件里tREFI配置，确认是按标准64ms周期配置的。
4. 定位到问题后，最稳妥的解法是换成支持温度补偿刷新的工业级颗粒，刷新周期可以自动缩短到32ms。
5. 短期内临时解法是手动把tREFI调整到3.9μs（等效32ms全阵列周期），牺牲部分性能换取稳定性。

这个案例的教训是：选型阶段如果产品使用环境可能超过85℃，就不能只盯着“常温能跑”，必须把刷新特性考虑进去。芯片标称的好不好，和你的工况合不合，是两回事。

5.3 排查刷新问题的三个关键工具

实战中，除了示波器和逻辑分析仪，还有三个免费的“软件工具”非常顶用：

• memtest86+：跑内存稳定性测试，能快速暴露位翻转问题，但注意它默认测试时序未必覆盖高温场景。
• 颗粒厂商的DS（Data Sheet）和配套计算表：很多厂商会提供Excel形式的时序计算工具，填上频率、tREFI、tRFC就能自动计算余量，强烈建议多利用。
• 内存控制器的调试寄存器：如果你用的是SoC，内存控制器一般会暴露很多现场状态，比如刷新计数、刷新增益、刷新延迟统计。定期读这些值，可以量化刷新对性能的影响。

6. 顺带说清两个易混概念：DRAM、DDR、PSRAM的关系，以及refresh token

6.1 DRAM是总称，DDR是其中之一，PSRAM是“伪装者”

很多刚入门的人会把DRAM和DDR画等号，这个不太准确。

DRAM（Dynamic Random Access Memory）是一大类存储器的总称，特点就是电容存储、需要刷新。它包含了历史上的SDRAM，也包含现在的DDR系列（DDR1到DDR5）、LPDDR系列（手机/平板）、GDDR系列（显卡）、以及各种嵌入式DRAM。

DDR（Double Data Rate）是DRAM的一种接口标准，它在一代SDRAM的基础上，通过上下沿都传输数据的方式，把吞吐量翻倍。所以“DDR内存”严格来说是“采用DDR接口的DRAM”。

PSRAM（Pseudo SRAM）就更有意思了。它的存储单元本质是DRAM，需要刷新的物理特性逃不掉，但芯片内部集成了刷新逻辑，外部接口做得和SRAM一样简单——不需要外部控制器干预刷新，直接像用SRAM一样读读写写就行。

所以你可以这样理解：

• DRAM是物理类别的总称
• DDR是DRAM的一种高速接口标准
• PSRAM是“内部用DRAM、外部装成SRAM”的混合体

选型时，如果主控不支持DDR控制器但需要大容量存储，PSRAM常是一个折中方案。代价是访问速度通常低于DDR，容量也没法做到很大。

6.2 refresh token和内存refresh完全是两个世界的“refresh”

开发应用的朋友可能对“Failed to refresh token: 400 bad request: invalid 'refresh_token': empty string”这类报错不陌生。这里的refresh token是OAuth 2.0等认证体系中的概念，指的是一个用于换取新访问令牌的凭证字符串。

报错信息说得很清楚：“invalid 'refresh_token': empty string”——也就是客户端传了一个空字符串给服务端，服务端自然不认。常见原因包括：

• 客户端代码里没正确保存refresh token，内存被清掉了。
• 请求参数名写错了，服务端没拿到有效字段。
• refresh token过期或被服务端吊销，返回的也是类似错误。
• 某些SDK在持久化token时出现空值写库，下次重启拿到空串。

这跟DRAM refresh八竿子打不着，唯一的共同点就是都叫refresh，一个管的是电容上电荷的物理存续，一个管的是会话凭证的逻辑续期。如果搜“refresh token”搜到一堆DRAM的资料，别慌，你的搜索词存在语义歧义，换个角度搜就是了。

写到最后的一点经验

回到开头说的那次高温排错，后来我养成了一个习惯：每块板子第一次调内存时，都会先把tREFI和tRFC按颗粒datasheet里的最保守值填上，然后设计一个温度梯度测试，确定系统实际工作温度后，再决定要不要“优化”刷新参数换取极限性能。这个习惯帮我避免过好几轮半夜去实验室救火。

DRAM刷新这件事，本质上就是一句话：你必须在电荷漏光之前，把数据再充满。但从这个物理底线，延伸出的参数计算、温度补偿、控制器调度、功耗设计、故障排查，每一环都有足够多的细节等你踩一遍。这篇基础小知识先帮你把骨架搭好，后面如果有机会，再单独写几篇讲讲刷新调度算法的实现细节和LPDDR自刷新状态机的时序图，欢迎持续关注。