ZigBee系统时间校准问题与解决方案

1. 芯科ZigBee系统时间问题深度解析

在嵌入式系统开发中，时间管理是个看似简单实则暗藏玄机的基础功能。最近我在调试基于Silicon Labs ZigBee SDK的智能网关项目时，遇到了一个由系统时间校准引发的"假死"问题，这个案例非常典型，值得深入剖析。

芯科ZigBee模块支持SOC和NCP两种工作模式。SOC模式下所有功能都在模块内完成，可以直接使用MCU的RTC或硬件定时器；而NCP模式需要主机配合，在Linux/Android平台上默认使用gettimeofday()获取系统时间。这个设计在大多数情况下工作良好，直到我们遇到时间校准这个特殊场景...

2. 问题现象与根因分析

2.1 问题复现路径

在我们的智能屏网关上，问题触发流程如下：

1. 设备启动时ZigBee初始化，系统时间从1970年开始计时
2. WiFi连接成功后同步网络时间（如2023年）
3. 已设置的定时器事件因时间基准突变导致计算异常
4. 线程进入长达49天的休眠（32位无符号整型溢出）

关键点：时间校准前后，halCommonGetInt32uMillisecondTick()返回值发生跃变，但已设置的定时器事件仍使用旧时间基准

2.2 底层机制拆解

SDK中时间相关的关键函数包括：

c复制// 获取当前系统时间(毫秒)
uint32_t halCommonGetInt32uMillisecondTick(void) {
    struct timeval tv;
    gettimeofday(&tv, NULL);
    return (tv.tv_sec * 1000) + (tv.tv_usec / 1000);
}

// 事件调度逻辑
void processEvent(uint32_t nowMs) {
    uint32_t duration = event->timeToExecute - nowMs;
    if(duration != 0xFFFFFFFF) {
        usleep(duration * 1000);
    }
}

当发生时间校准时，假设：

• 设置定时器时nowMs=1000（从1970年算起）
• 执行时nowMs=1672531200000（校准