以太网温湿度变送器双协议兼容（TCP+SNMP）固件调试笔记

以太网温湿度变送器双协议兼容（TCP+SNMP）固件调试笔记

物联网 · 盛世宏博 · 以太网温湿度、双协议兼容、Modbus TCP、SNMPv3、固件调试、并发冲突、MIB设计、写后回读、动环平台

近期在调试一套工业环境监控系统时，遇到了关于Modbus连接保持的问题。把场景收束到固件层：一台以太网温湿度变送器，要同时跑Modbus TCP（给动环平台采数据）和SNMP（给网管系统做资产/健康/告警纳管）。两个协议栈共享同一套传感硬件和寄存器映射，调试中踩到的坑不是“通不通”，而是“两个栈同时动硬件时谁赢、SNMP写操作怎么和Modbus写操作不打架、MIB怎么设计才不让NMS把传感器当路由器轮询爆”。

一、双协议共存的硬件与OS底座

• MCU：Cortex-M7（如STM32H7）或 MIPS/Linux SoC（如RT5350），带MAC+PHY或外扩以太网
• 传感器接口：I2C/SPI接SHT35/HTS221，16bit ADC，PT1000经PGA
• 协议栈：lwIP（裸机/RTOS）或 Linux netdev + net-snmp（裁剪版）
• 供电：PoE 802.3af或PoE+DC双输入

关键约束：Modbus TCP和SNMP都跑在TCP/IP之上，但语义模型完全不同——Modbus是“寄存器读写”，SNMP是“OID Get/Set/Trap”。两套栈必须共享同一个设备状态数据库（DS），且对这个数据库的访问必须互斥。

二、共享数据结构的互斥设计

┌─────────────┐
│  传感采集线程  │ 2s周期读I2C/ADC → 写DS（温度/湿度/露点原始值）
└──────┬──────┘
       │
┌──────▼──────┐     ┌──────────────┐
│   DS（受保护） │←──→│  互斥锁/临界区  │
└──────┬──────┘     └──────────────┘
       │
   ┌───┴────┬─────────┐
   │        │         │
┌──▼──┐ ┌──▼──┐ ┌───▼───┐
│Modbus│ │SNMP │ │ Trap  │
│TCP   │ │Agent│ │线程   │
└──────┘ └─────┘ └───────┘

规则：

• DS中每个字段标注访问权限：采集线程=写者，协议栈=读者（测量值）；配置字段=协议栈可写，写后需同步到Flash
• 用自旋锁或mutex保护DS，禁止两个协议栈同时写同一配置字段
• Modbus写寄存器（功能码0x06/0x10）和SNMP SetRequest必须走同一个配置写入入口函数，该函数内部再上锁
• 测量值（温度/湿度）只允许采集线程更新，协议栈只读

三、Modbus TCP侧实现要点

3.1 寄存器映射（与SNMP MIB平行对照）

保持寄存器（0-based）：
0x00: temp      int16 ×0.1℃     RO
0x01: humi      uint16 ×0.1%RH   RO
0x02: dewpoint  int16 ×0.1℃     RO
0x03: status    uint16 bitfield  RO
0x04: fault     uint16 bitfield  RO
0x05: sample_int uint16 采样周期 RO/RW
0x06: th_temp   int16 高温阈值   RW
0x07: th_humi   uint16 高湿阈值  RW
0x08: snmp_ver  uint16 0=v2c 1=v3 RW
0x09: sys_contact ascii[64]     RW

3.2 事务处理

• MBAP头：事务ID自增，响应原样回传
• 功能码：0x03读、0x06单写、0x10多写
• 每个TCP连接一个会话上下文，不跨连接共享事务ID
• 写寄存器后：更新DS→写后回读校验→返回异常码（非法值/只读/忙则返0x83/0x90）

四、SNMP Agent侧实现要点

4.1 MIB设计（私有分支）

MY-COMPANY-MIB ::= BEGIN

SensorObjects OBJECT IDENTIFIER ::= { enterprises 12345 1 }

tempValue      OBJECT-TYPE  SYNTAX Integer32  UNITS "0.1C"  ACCESS read-only  STATUS mandatory
              ::= { SensorObjects 1 }
humiValue      OBJECT-TYPE  SYNTAX Unsigned32 UNITS "0.1%"  ACCESS read-only  STATUS mandatory
              ::= { SensorObjects 2 }
dewPointValue  OBJECT-TYPE  SYNTAX Integer32  UNITS "0.1C"  ACCESS read-only  STATUS mandatory
              ::= { SensorObjects 3 }
sensorStatus   OBJECT-TYPE  SYNTAX BITS { running(0), alarm(1), cached(2), offline(3) }  ACCESS read-only
              ::= { SensorObjects 4 }

-- 配置项
tempHighThresh OBJECT-TYPE  SYNTAX Integer32  ACCESS read-write  STATUS mandatory
              ::= { SensorObjects 10 }
humiHighThresh OBJECT-TYPE  SYNTAX Unsigned32 ACCESS read-write  STATUS mandatory
              ::= { SensorObjects 11 }
snmpVersion    OBJECT-TYPE  SYNTAX INTEGER { v2c(0), v3(1) }  ACCESS read-write  STATUS mandatory
              ::= { SensorObjects 12 }

-- Trap定义
sensorAlarmTrap NOTIFICATION-TYPE  OBJECTS { tempValue, humiValue, sensorStatus }
              ::= { SensorObjects 100 }
END

4.2 Agent行为

• GetRequest：从DS读当前值，直接返回
• GetNext/GetBulk：按MIB树遍历，注意GetBulk在v2c中可能被NMS滥用→固件端限制Max-Repetitions≤10
• SetRequest：调同一个配置写入入口→校验权限/范围→更新DS→持久化到Flash→返回应答
• Trap：越限事件触发，目标地址从配置读取（最多3个Trap目标），支持v2c Trap和v3 Inform

五、并发冲突调试中踩到的坑

坑1：Modbus写阈值 vs SNMP Set阈值，Flash写冲突

现象：同时用Modbus和SNMP改阈值，偶尔丢一个值，Flash里只存了其中一个。

根因：两个协议栈各自直接调Flash写函数，无互斥，Flash页擦除中途被打断。

修复：统一入口 cfg_write(key, value) → 上mutex → 改RAM副本 → 擦写Flash → 释放mutex。Modbus和SNMP都只能调这个入口。

坑2：SNMP GetBulk把MCU问死

现象：NMS做自动发现，发GetBulk Max-Rep=50，MCU lwIP TCP窗口满，后续Modbus连接全部超时。

根因：SNMP Agent在裸机lwIP中同步处理，GetBulk 50次迭代占CPU太久，阻塞了其他协议任务。

修复：

• 限制Max-Repetitions硬上限=10
• SNMP Agent移到独立任务/线程，与Modbus TCP同优先级轮转
• 大MIB遍历分片，单次处理不超过5ms，yield给其他任务

坑3：Trap风暴

现象：湿度在阈值边界抖动，SNMP Trap每秒发3~5个，交换机CPU飙高。

根因：越限即发Trap，无防抖/抑制窗口。

修复：

• 边沿触发：进入越限状态才发Trap，恢复后才发Clear Trap
• 退避抑制：同一OID的Trap最短间隔60s
• 连续3次采样确认越限才触发（与Modbus侧判据一致）

坑4：SNMP v3引擎启动延迟导致Modbus握手慢

现象：启用SNMP v3后，Modbus TCP连接建立时间从<100ms变成1~2s。

根因：SNMP v3引擎初始化时做了大量随机数生成（getrandom阻塞），占用了entropy源，lwIP TCP accept被延迟。

修复：SNMP v3引擎在系统启动早期初始化，不放在第一个连接到来时懒加载；用硬件RNG（如STM32 RNG外设）替代/dev/urandom。

坑5：字节序——SNMP INTEGER vs Modbus int16

现象：Modbus读温度=235（=23.5℃），SNMP读出来=58890（负数解译错误）。

根因：SNMP Agent直接把Modbus寄存器原值当uint16返回，没做符号扩展。

修复：DS中温度存int16_t，SNMP Agent读DS时做正确的ASN.1 INTEGER编码（含符号位）。

六、调试工具链与定位方法

调试口诀：

• 先Ping通→再nc 502→mbpoll读原始值→snmpwalk遍历MIB→交叉比对
• 任何不一致先查DS，再查协议编码，最后查硬件

七、固件配置默认参数建议

Modbus TCP：
  Port: 502
  Unit ID: 1（可配）
  Timeout: 300ms
  Max Connections: 5
  Transaction ID: 自增

SNMP：
  Port: 161
  Trap Port: 162
  Version: v3（默认），兼容v2c可配
  Read Community: 独立配置（不硬编码public）
  Write Community: 独立配置
  v3 User: 可配，SHA/AES
  Max-Repetitions 上限: 10
  Trap Targets: 最多3个
  Trap Interval Min: 60s

系统：
  Sample Period: 2s
  Heartbeat LED: 1Hz
  Watchdog: 启用，超时15s复位
  Flash Write Debounce: 5s（配置变更后延迟5s批量写Flash）

八、验收测试清单

□ Modbus读所有RO寄存器：值与snmpwalk一致（±1LSB）
□ SNMP Set改阈值：Modbus读回同一值，Flash断电不丢
□ Modbus写阈值：SNMP Get返回同一值
□ 并发：mbpoll循环读 + snmpwalk同时跑，无死锁、无数据错乱
□ GetBulk Max-Rep=50：Agent截断到10，不崩溃
□ Trap：越限触发，60s内不重复；恢复发Clear
□ v3加密：Wireshark解密验证隐私数据
□ 断网：拔线→重连→两个协议栈均自动恢复监听
□ 72h老化：无内存泄漏、无mutex死锁、无假在线
□ 写后回读：Modbus写非法值（如RH=150%），返回异常码，DS不变

九、关键经验

1. 双协议固件不是“两个协议栈各跑各的”，是“两个协议栈共享同一份数据，谁写谁说了算要靠互斥”。
2. 配置写入必须走单一入口函数，Modbus和SNMP都是这个函数的调用者，Flash写冲突才能根除。
3. SNMP GetBulk是MCU杀手——NMS不客气，固件端必须限Max-Rep，否则一个自动发现就能把整台设备问瘫。
4. Trap是SNMP的灵魂也是风暴源：边沿触发+退避窗口，和Modbus告警判据用同一套状态机。
5. 字节序/符号扩展在双协议下翻倍出bug：Modbus是寄存器视角，SNMP是ASN.1视角，DS是唯一的“真相源”。
6. v3安全不是可选项：等保/金融/电力项目明文v2c过不了审计，固件启动阶段就把v3引擎初始化好。
7. 调试顺序不能跳：先物理层→再TCP连通→再单协议验证→再双协议并发→最后72h老化。
8. 串口日志在协议调试中不可替代：Wireshark只能看到线上字节，看不到mutex争用和Flash操作结果。
9. 固件交付物不是“固件.bin”，是寄存器映射表+MIB文件+默认参数表+Wireshark抓包样例。
10. 写后回读在SNMP侧同样适用：SetRequest返回success≠设备真的改了，Agent内部也要读回DS确认。

十、关键词

以太网温湿度、双协议兼容、Modbus TCP、SNMPv3、固件调试、MIB设计、并发互斥、写后回读、Trap抑制、动环平台

物联网 #工业物联网 #以太网温湿度 #ModbusTCP #SNMP #固件开发 #双协议 #嵌入式 #动环监控 #环境监控平台 #MIB #写后回读