nRF定时器中断调试实战：从事件机制到ISR纪律

做低功耗无线项目的朋友，多半都有过这种经历：拿一块nRF系列芯片的板子想做个定时器点灯，结果“中断进不去”“进一次就不进了”“中断明明进了，时间却完全不对”轮番上阵。我自己在nRF52840和nRF52832上调试定时器+中断踩过不少坑，最后发现绝大多数问题不在芯片本身，而是对这套“事件-中断”模型的理解还停留在传统单片机的思路上。这篇就把我在nRF定时器+中断上真正碰到过的问题、排查思路和修复方法整理出来，给正在Debug边缘的朋友做个参考。

1. 先理清nRF定时器中断的完整链路：事件、INTEN与NVIC缺一环都不行

nRF的定时器外设设计思路和很多传统单片机不一样：计数器COUNTER与某个比较寄存器CC[n]相等时，硬件只做一件事——把对应的事件寄存器EVENTS_COMPARE[n]置1。这个事件寄存器只是“硬件事件已经发生”的标记，它不会自动帮你调用中断。从事件变成CPU进入ISR，中间还要经过INTENSET配置的“中断使能”，以及Cortex-M内核NVIC的IRQ使能。任何一级没配好，表现都是“定时器没中断”，但根因完全不是一回事。

1.1 nRF定时器的“事件机制”到底改了什么

传统单片机一般在定时器溢出时直接触发固定中断，标志位由硬件置位，软件负责清除，整个链路是同一条路。nRF这边拆得更细：

计数器COUNTER和CC[n]相等 → 硬件把EVENTS_COMPARE[n]写1 → 如果INTENSET对应位是1，外设才向NVIC发出中断请求 → NVIC挂起后CPU进入ISR。

最关键的一点是：进入ISR之后，EVENTS_COMPARE[n]依然是1，必须由软件写0清除。你清不掉旧事件，后续再发生比较事件时，新事件和旧事件会粘在一起，表现出来就是“好像少进了一次中断”，或者“连续进了两次但只处理了一次”。

注意：清除事件寄存器的方法是直接写0，例如NRF_TIMER1->EVENTS_COMPARE[0] = 0;。不是写1，不是读清零，这一点和很多外设不一样。

我见过不少人在ISR里写if (NRF_TIMER1->EVENTS_COMPARE[0])判断事件，却忘了手动清事件。结果第一次中断正常，第二次开始行为随机，时间一长整个软件定时逻辑全乱。

1.2 中断链路上每一级失效的不同表现

既然链路分了好几级，每一级出错的表现就不一样。我用一张表整理一下，排查时对号入座：

排查顺序我建议固定成：事件位 → INTEN → NVIC挂起位 → ISR。事件位是0，说明问题在外设配置；事件位是1但INTEN是0，说明只是没放行；两者都是1但不进ISR，大概率卡在NVIC或者系统临界区。

2. 只进一次中断或周期不对：CC装载与SHORT自清零的细节坑

“定时器第一次中断正常，之后就再也不进”是nRF定时器+中断最经典的问题。你查寄存器发现中断配置没问题，ISR也会执行一次，但第二次事件就是不来。

2.1 “第一次进去了，之后就再也不进”的常见原因

绝大多数情况是这两类：

第一，事件没清。这一点我前面说过了，第一次事件触发后EVENTS_COMPARE[0]一直保持1，虽然ISR执行过，但外设认为事件还没被消费，后续比较事件的边沿没法再产生新的有效中断请求。这是最常见的原因，也是最容易修的。

第二，计数器没有按预期回到起点。很多传统单片机定时器溢出后会从0重新计数，nRF不是这样。你启动定时器后，如果CC值配置为比如1000，计数器会从0一直涨到定时器满位或者被外部清零，并不自动回到0。第一次比较事件发生在COUNTER到达1000时，第二次比较要等到计数器再次到达1000。如果计数器已经跑到远远超过1000并且停在最大值或者继续循环，那第二次比较事件的间隔会变成一个你根本猜不到的数字，甚至永远等不到。

所以，周期定时器必须处理“清零/重载”这一步。处理方式有两种，一种是软件在ISR里手动清，一种是用SHORT机制让硬件自动清。软件手动清有个隐蔽问题：从比较事件发生到ISR真正执行之间，计数器一直在走，等你在ISR里执行TASKS_CLEAR时，多走的这部分时间也被清掉了。这样第一个周期是整数，第二个周期会变成“整数+ISR延迟”，第三个又稍微不同，定时器周期永远对不齐。

2.2 周期是CC+1还是CC：一个微妙的偏移

关于CC值还有个容易踩的偏移。nRF计数器的行为是从0递增到CC，也就是说从启动到第一次比较，一共走了CC + 1个tick。如果时钟是1MHz，一个tick是1微秒，你想要1ms周期，CC要填999，不是1000。填1000的话实际周期是1.001ms，单看不明显，做长时间累计或者对时间敏感的应用时就会露馅。

我把这段代码贴出来，这是1MHz时钟下产生标准1ms周期中断的起始配置：

NRF_TIMER1->MODE = TIMER_MODE_MODE_Timer; NRF_TIMER1->BITMODE = TIMER_BITMODE_BITMODE_24Bit; NRF_TIMER1->PRESCALER = 4; // 16MHz / 2^4 = 1MHz，一个tick = 1us NRF_TIMER1->CC[0] = 999; // 999 + 1 = 1000 ticks = 1ms NRF_TIMER1->SHORTS = TIMER_SHORTS_COMPARE0_CLEAR_Msk; NRF_TIMER1->INTENSET = TIMER_INTENSET_COMPARE0_Msk; NVIC_SetPriority(TIMER1_IRQn, 1); NVIC_EnableIRQ(TIMER1_IRQn); NRF_TIMER1->TASKS_START = 1;

注意SHORTS配置了COMPARE0_CLEAR，意思是当比较事件发生时，硬件自动把COUNTER清回0，完全不占用CPU时间。这样周期性就稳定了。

2.3 用SHORT省掉手动清计数器的正确姿势

如果你只是想要固定周期的中断，强烈建议用SHORT自动清计数器，而不是在ISR里手动写TASKS_CLEAR。原因就是上面说的ISR延迟。自动清能保证周期纯粹由硬件决定，精确度只取决于时钟源，和中断响应时间无关。

ISR里只需要做两件事：清事件、置标志：

void TIMER1_IRQHandler(void) { if (NRF_TIMER1->EVENTS_COMPARE[0]) { NRF_TIMER1->EVENTS_COMPARE[0] = 0; g_timer1_tick = 1; // volatile全局标志 } }

如果你需要动态调整下一次中断时间，还有另一种思路：不用SHORT，不清计数器，而是在ISR里直接把CC值加上周期tick。比如每次ISR里执行NRF_TIMER1->CC[0] += 1000;，让中断目标变成“绝对计数值”，这样即使中断响应晚了，下一个目标点仍然是未来某个固定的计数值，长时间看不会累积偏差。不过这要求ISR执行时间足够短，如果CC目标已经被超过，事件会立刻再次触发，那就会变成连锁中断。

3. ISR里干活太重，定时器精度就全毁了

定时器配置好了，中断也稳定进了，接下来最常见的问题是“定时器周期明明设好了，实际跑起来却忽长忽短”。这时候别急着怀疑定时器，先把目光放回ISR。

3.1 实测现象：1ms的定时器测出了忽长忽短的间隔

我调试过一个例子，定时器配置1ms中断一次，ISR里直接调用了一个库函数去发送一小段数据。函数内部有等待标志位的循环，正常情况下几百微秒能完成。结果实测中断间隔不是1ms，而是1ms、2ms、3ms随机跳动。用示波器看引脚翻转，波形毛刺非常明显。

原因是ISR执行时间几乎占满了整个周期，甚至偶发超过周期。当ISR还没退出来，下一次比较事件已经发生并挂起，等ISR结束后会立刻再次进入ISR，导致间隔表现为“上一周期极短，下一周期很长”。这种问题肉眼很难排查，因为你感觉中断一直在进，但时间轴已经被打乱。

3.2 为什么“低优先级中断里调库函数”会连环炸

更隐蔽的是在ISR里调用某些带锁或者忙检查的库函数。很多nRF SDK的驱动函数不是完全可重入的，它们内部有状态标志、忙检查、甚至临界区。你在ISR里调用传输函数，主循环刚好也在调用同一个驱动，就可能出现一方拿到锁，另一方一直等，最后整个系统卡死的局面。

还有一种情况：在ISR里等待HFCLK相关事件。nRF定时器时钟依赖HFCLK，但其他外设也可能需要HFCLK。如果在ISR里做操作时正好芯片从某种低功耗状态恢复，HFCLK还在启动稳定过程中，你等一个时钟事件就可能等几十到几百微秒。这几十微秒放在1ms周期任务里已经足够致命。

所以我在项目里给自己定了纪律：硬件定时器ISR里只做三件事，清事件、置volatile标志、必要时唤醒一个等待者（比如通过信号量或者事件组）。所有对外设的操作、协议处理、数据打包全部放到主循环或者低优先级任务里。

3.3 推荐的ISR纪律：清事件+置标志+丢队列

直接给一个可以抄的骨架：

volatile uint8_t g_timer1_tick; void TIMER1_IRQHandler(void) { NRF_TIMER1->EVENTS_COMPARE[0] = 0; g_timer1_tick = 1; } int main(void) { /* 初始化定时器和外设 */ while (1) { if (g_timer1_tick) { g_timer1_tick = 0; handle_periodic_work(); // 所有耗时操作放这里 } /* 其他主循环任务 */ } }

如果项目用了nRF5 SDK的app scheduler，也可以把耗时操作通过app_sched_event_put()丢到主循环队列里执行。这样ISR保持微秒级短促，主循环有足够时间去处理业务，并且不会互相阻塞。

4. 别把app_timer当成硬件TIMER中断来理解

很多初用nRF5 SDK的人，会在看到app_timer_create、app_timer_start后以为这就是“定时器中断”，然后往里塞各种操作。其实app_timer和硬件TIMER中断完全是两码事，理解错了会踩坑。

4.1 app_timer的回调其实跑在RTC0的中断上下文里

app_timer是SDK里的软件定时器模块，底层用的是RTC0，时钟源是LFCLK（典型32.768kHz）。你创建的每个app_timer到期后，SDK会在RTC0的ISR里遍历定时器列表，然后同步调用你的回调函数。

也就是说，app_timer回调执行时，CPU正处于RTC0中断上下文里。它不是有一个独立的中断线程，而是被“塞”在别人的ISR里执行。这一点很多人一开始都不知道：

APP_TIMER_DEF(my_timer); static void my_timer_cb(void *p_ctx) { // 注意：这个回调执行时，CPU在RTC0中断上下文里 } void main(void) { app_timer_init(); app_timer_create(&my_timer, APP_TIMER_MODE_REPEATED, my_timer_cb); app_timer_start(my_timer, APP_TIMER_TICKS(1000), NULL); }

如果这个回调里只做置标志、挪数据，那没问题。但如果里面调用了阻塞等待函数、长时间轮询、大块Flash写入，那整个RTC0中断都会被拖住。RTC0不仅服务app_timer，还经常被低功耗协议栈、系统tick、SDK其他模块使用。拖住它，可能连协议栈调度都会出问题。

4.2 在app_timer回调里做耗时操作，拖垮的不是只有你

我有一次在app_timer回调里顺手刷新了一个LCD段码屏，刷新函数本身要等待某个引脚的状态翻转。结果这个刷新逻辑占用的时间一长，RTC0中断超过了阈值，系统里其他所有软件定时器全部跟着抖动，连按键长按检测都失灵了。

排查过程也很典型：把按键检测和LCD刷新都改成单独的外设中断，问题依旧；最后把所有中断屏蔽掉，只留RTC0，再跑一遍，才发现是app_timer回调堵住了RTC0。换到主循环里执行后，所有定时器恢复稳定。

4.3 什么时候该用app_timer，什么时候必须用硬件TIMER

我现在的选择标准很简单：

• 毫秒级或更粗的周期任务、需要低功耗定时喂狗、回调任务本身很轻量 → 用app_timer，灵活且省电。
• 需要微秒级精确控制、周期在亚毫秒、有严格的时间确定性要求 → 用硬件TIMER，配合中断自己管理。
• 需要在低功耗唤醒后做精确时间测量 → 用RTC事件或者硬件TIMER的捕获功能，而不是靠app_timer回调计数。

如果你不确定该用哪个，先问自己一个问题：回调里要做的事如果被延后100微秒，会不会出问题？不会，用app_timer；会，用硬件TIMER。

5. 一次“定时器中断偶现丢失”的完整排查链路复盘

前面说的都是比较直接的错误，下面复盘一个更隐蔽的问题，也是我在实际项目里花了好几天才定位的。

5.1 故障现象：跑一段时间后偶现一次间隔翻倍

系统里有一个1ms硬件TIMER中断，ISR里只做标志位翻转，主循环根据标志翻转一个小灯。刚开始测试时一切正常，但长时间运行后，小灯偶尔会“卡”一下，用逻辑分析仪量引脚，发现每隔随机时间会出现一次2ms到3ms的间隔，好像丢了一次中断。

我首先怀疑CC值和SHORT配置，但检查过都没问题。ISR也很轻量，不可能是自身执行太久。后来我在ISR里加了一个自由运行的参考定时器，把它当时间尺，测量相邻两次进入ISR的真实间隔。

5.2 逐级排查：事件是否产生、中断是否使能、CPU为何延迟响应

参考定时器的做法是：再多开一个硬件TIMER，不配置任何中断和比较事件，只让它自由计数，当作一个不停走的时间戳。然后在目标ISR里记录相邻两次进入时的参考计数器差值：

// 假设 TIMER2 作为自由时间尺，PRESCALER=4，1MHz static uint32_t last_counter; void TIMER1_IRQHandler(void) { NRF_TIMER1->EVENTS_COMPARE[0] = 0; if (NRF_TIMER2->COUNTER > last_counter) { timer_gap = NRF_TIMER2->COUNTER - last_counter; } else { timer_gap = (UINT32_MAX - last_counter) + NRF_TIMER2->COUNTER + 1; } last_counter = NRF_TIMER2->COUNTER; if (timer_gap > 1100) { // 期望1000 tick左右，超过10%就异常 g_anomaly_count++; } }

跑了一段时间后，异常计数器确实递增，而且和某些外设操作的时间点高度重合。这时候我再回到寄存器层面验证：在异常发生后的片刻暂停，查看EVENTS_COMPARE[0]、INTENSET、NVIC->ISPR。

结论是：EVENTS_COMPARE[0]已经为1，INTEN也为1，但NVIC->ISPR对应的中断挂起位也为1，CPU却一直没进入ISR。这说明中断请求已经到达NVIC，但被更高优先级或者临界区挡住了。打开调试器定位，发现这线程里有一段外部Flash擦除操作，库函数进入临界区后关闭了全局可屏蔽中断几百微秒。临界区期间，TIMER事件依然会置位、NVIC依然会挂起，但CPU就是不响应。等退出临界区，ISR才补执行，硬件计数器却已经多走了一大截。

5.3 根因确认与修复：别在ISR里假设时间均匀流逝

这次“丢中断”其实是“中断延迟响应”，并不是真正丢掉了硬件事件。中断被延迟后，标志位翻转依旧会发生，但相邻两次ISR的实际间隔因为延迟而拉长。

修复方式不是简单提高TIMER中断优先级，因为临界区关的是全局可屏蔽中断，优先级再高也会被挡。我从根本上调整了两个地方：

第一，把写入Flash之类的耗时操作拆成小块，尽量减少临界区占用的时间，保证最长临界区控制在定时器周期的1/10以内。

第二，不再假设“每次进入ISR就是固定间隔”，而是用参考定时器记录真实时间戳。业务侧计算时间差，而不是简单累加中断次数。这样即使偶尔发生延迟，也不会造成业务累积误差。

修复后再跑两小时，异常计数从几十次降到了0。这个案例让我印象很深：定时器中断“貌似丢失”时，先别急着改定时器配置，用额外时间尺量一量真实间隔，往往能直接看到问题在哪一段。

6. 长期实用建议：让nRF定时器+中断少出幺蛾子的几条纪律

最后聊几条我长期积累下来的实用建议。虽然没有大篇幅代码，但能帮你少走很多弯路。

6.1 调试时先看寄存器，别盲目加日志

nRF的定时器问题，80%都能通过读寄存器直接定位。我的标准动作是：进调试器，暂停CPU，依次看EVENTS_COMPARE[n]、INTENSET、NVIC->ISPR、NVIC->IABR，再通过位带或者变量窗口看COUNTER和CC[n]的关系。直接读寄存器得到的现场信息，比加一堆打印日志准确得多，因为日志本身会引入延迟和中断干扰。你如果打日志后发现异常频率变了，那说明日志干扰了时间轴，这时候更要靠寄存器。

6.2 定好时间基准：短周期高精度用TIMER，长周期低功耗用RTC

nRF系统里有两套时间基准：HFCLK和LFCLK。硬件TIMER跑在HFCLK上，短期精度高，但有功耗代价，而且从低功耗唤醒后要等HFCLK稳定才能走时；RTC跑在LFCLK上，常年可运行，功耗低，但频率低，精度有限，app_timer就是基于它。

我的项目分层是：长时间休眠、秒级到分钟级调度用RTC；唤醒后需要做波形输出、协议时序、微秒级测量时，再启动硬件TIMER。不要让一个硬件TIMER既干长周期计时的活，又干高精度中断的活，否则两边都做不好。

6.3 ISR职责边界要清晰：清事件、置标志、唤醒等待者

这条虽然前面已经提过，但它值得单独列为长期纪律。ISR里能做的事就三样：清事件寄存器、置位volatile标志或信号量、唤醒一个明确的事件等待者。任何超出这个边界的操作，都要先问自己“能不能放到主循环？能不能放到队列里？”

如果你现在正卡在nRF定时器+中断的坑里，我的建议是先别急着改代码，打开调试器把EVENTS_COMPARE[n]、INTENSET、NVIC->ISPR这三个值拍下来，八成问题已经写在那里了。等这三个寄存器状态都正常，再考虑时钟源、临界区、ISR负载这些外围因素，排查效率会高很多。