LoRaWAN协议栈在STM32上的移植：从MAC层定时器到Region参数的完整适配

LoRaWAN协议栈在STM32上的移植，难点不在MAC层逻辑本身——Semtech的LoRaMac-node已经把入网、加密、帧计数这些逻辑写好了。真正需要工程师动手的，是让这套协议栈“感知”STM32的时钟节拍，并“认识”目标市场的信道规则。这两件事分别对应定时器适配和Region参数配置，任何一项出错，表现出的症状都是“入网失败”或“下行收不到”，但根因往往藏在毫秒级的时序偏差或频段宏定义里。

定时器适配：RTC闹钟链表而非SysTick

LoRaWAN的RX1/RX2窗口对时间精度要求苛刻。EU868的接收延迟1为1秒、延迟2为2秒，窗口开启时刻偏差超过几十毫秒，网关的下行帧就可能已经发完。许多移植失败案例的根因，是开发者用SysTick或普通定时器去驱动协议栈的`Timer`模块，导致在低功耗模式下定时中断丢失。

LoRaMac-node的定时器设计有其独特之处。它没有采用“1ms嘀嗒、每次遍历链表”的常规做法，而是构建了一个基于RTC闹钟的事件链表：每个定时事件记录的是“距离上一次闹钟设置的剩余时间”，表头事件直接对应下一次RTC闹钟的触发时刻。这种设计的效率优势在于，无论链表中有多少定时事件，RTC只需要在表头事件到期时触发一次中断，无需周期性轮询。

移植到STM32时，`rtc-board.c`需要重写为使用STM32的RTC Alarm功能。关键实现点包括：RTC时钟源选择LSE(32.768kHz)以保证低功耗模式下的走时精度;`RtcSetAlarm`将协议栈传入的`TimerTime_t`(毫秒)转换为RTC的日历或亚秒计数值;`RtcGetElapsedAlarmTime`负责计算当前时刻与目标时刻的差值。GitHub上有一个已知的STM32 RTC适配问题值得警惕：使用四舍五入后的毫秒值计算时间差，可能引入1ms的偏差，导致定时器回调偶尔被“跳过”而停滞。修复方式是使用精确的双精度值进行差值计算，并在溢出场景下补上单位增量。对于RX窗口这种对时序敏感的场景，这1ms的误差在多数情况下可以容忍，但若叠加其他延迟(如射频切换时间)，就可能成为压垮骆驼的最后一根稻草。

Region参数：编译期开关与运行期选择

Region配置决定了设备在哪个频段、用哪些信道、遵守什么占空比规则。LoRaMac-node将Region实现为独立的源文件(如`RegionEU868.c`、`RegionCN470.c`)，通过宏定义在编译期决定哪些Region被包含进固件。

在STM32CubeWL的官方框架中，这一配置集中在`lorawan_conf.h`。需要同时完成两件事：第一，用`#define REGION_XXX`打开目标Region的编译开关;第二，用`#define ACTIVE_REGION LORAMAC_REGION_XXX`指定设备上电后默认使用的Region。只做前者不做后者，设备可能仍以默认Region(通常是EU868或CN470)启动，导致在目标市场无法入网。ST的AN5406应用笔记明确列出了这一配对要求，并提醒：编译时可以启用多个Region，但`ACTIVE_REGION`只能有一个。

Region参数中容易被忽略的是RX2窗口的默认配置。以EU868为例，`RegionEU868.h`中定义了`EU868_RX_WND_2_FREQ`为869525000 Hz、`EU868_RX_WND_2_DR`为DR_0。这意味着设备在未收到网络下发的RXParamSetupReq命令前，会以869.525MHz/SF12打开第二个接收窗口。如果网关侧的配置与此不一致，下行帧将无法被设备捕获。对于CN470等频段，Region参数中还包含信道掩码和子频段选择，需与网络服务器的配置严格对齐。

分层移植的实践顺序

工业Monitor Direct的指南给出了一个值得遵循的移植顺序：先验证SPI和射频驱动能完成点对点收发，再移植协议栈的无线电控制和系统定时器接口，最后处理Region和入网参数。这一顺序的逻辑是：P2P成功证明射频链路是通的，接下来如果入网失败，问题就被限定在协议栈的时序或参数配置上，而非硬件故障。

具体到代码层面，建议将移植拆分为三个独立的验证节点。第一，Radio接口：确认`Radio.SetTxConfig`、`Radio.Send`、`Radio.Rx`能正确驱动SX1262/STM32WLE内置射频，DIO1中断能触发`OnTxDone`/`OnRxDone`回调。第二，Timer接口：在`rtc-board.c`完成后，用协议栈的`TimerSetValue`设置一个100ms定时器，用GPIO翻转验证实际触发时刻与设定值的偏差在可接受范围内。第三，Region与Join：选择目标Region，用OTAA入网，通过网关日志确认Join Request是否被正确解码。若网关收到但NS拒绝，检查DevEUI/AppKey和DevNonce策略;若网关未收到，回到Radio层检查发射频率和功率配置。

结语

LoRaWAN协议栈在STM32上的移植，本质上是为Semtech的MAC状态机提供两个“锚点”：一个精确的时钟源(RTC闹钟链表)，和一套正确的区域规则(Region编译宏与ACTIVE_REGION配对)。定时器的毫秒级偏差会让RX窗口错位，Region的宏定义遗漏会让设备“用错误的地图找路”。这两个锚点固定之后，协议栈自身的Join流程、加密和帧计数逻辑便可按原设计运行。移植的验收标准不是“编译通过”，而是“网关日志显示Join Request被正确接收，且设备在RX1/RX2窗口内成功捕获Join Accept”。