set_upgrade_s5.c

源文件路径：midware/inverter/set/set_upgrade_s5.c 所属模块：midware/inverter/set（盛能杰 S5 / S5-II / M10 逆变器通信） 代码行数：727

1. 文件职责

本文件实现盛能杰 Smile5 系列（SUB_S5 / SUB_S5_II / SUB_M10）逆变器主控 DSP、从机 DSP 与 DCDC(ARM) 模块的串口 Bootloader 固件升级。它处在"云端下发固件 → UART2 逐块搬进 SDRAM（g_u8_fw_sdram1/2）→ 本文件通过 UART2 把固件写入逆变器"这条链路的末端，是整个过程唯一真正与逆变器 Bootloader 对话的代码。

它由 midware/inverter/inverter.c:1090 的 task_inverter（uCOS-II 任务，周期 80 ms，inverter.c:1188）→ set_comm_usart_s5.c:6199 的 senergys5_inverter_comm() 周期调用：一旦发现固件已下载完成就把正常遥测通信让位给升级流程。状态机的每一次进入只推进"一步"（发一帧或发一个 2 KB 数据块），靠 s_senergys5_upgrade_info.upgrade_status 在多次调用之间保持进度。

进度与标志通过 inverter.c 的 inverter_read_upgrade_flag_* / inverter_read_upgrade_percent_* 聚合后上报云端与 HMI（inverter.c:3812/3847/3882/3917/3976/4003）。

2. 关键数据结构与宏

2.1 本文件定义/持有的对象

2.2 本文件主要使用的宏

2.3 逆向出的协议字段（本文件以内联常量形式写死，无宏）

3. 函数清单

4. 核心逻辑解析

4.1 状态机总览与迁移条件

switch (s_senergys5_upgrade_info.upgrade_status) 位于 :439：

ENTER_BOOT ──成功──► SHAKE_HANDS ──成功──► SEND_FILE_PROPERTIES ──成功──► SEND_UPGRADE_FILE
   │ 失败×5                │ 失败×5                 │ 失败×5                     │
   └──重试(SHAKE_HANDS)    └──► END                └──► END                     │
                                                    ▲                          │
                       （对象=MASTER 且版本回读成功）│              块数用尽/失败×5
                                                    └──────────  UPGRADE_END ◄──┘

• SENERGYS5_ENTER_BOOT（:441-516）：清零版本查询计数器，按优先级 master → slave → dcdc 选定对象，填 u8_upgrade_addr（主机/ DCDC 用 g_u8_fw_sdram1，从机用 g_u8_fw_sdram2）、u32_upgrade_file_len（get_length_file_updating(UPDT_INV1/2/3)）以及 9 字节命令字段。三个 flag 都为 FALSE 时直接置 UPGRADE_END 返回（空闲态，:491-498）。

成功（收到期望应答码）→ SHAKE_HANDS；失败 err_count++，累计到 5 次时不清 END 而是回到 SHAKE_HANDS（:509-514，这是唯一"越级前进"的分支，见 7.3）。

• SENERGYS5_SHAKE_HANDS（:518-541）：把 u8_upgrade_buf[8]（0x55/0x56/0x62）单字节发出，等 0xA5。成功 → SEND_FILE_PROPERTIES；失败 5 次 → UPGRADE_END（放弃）。
• SENERGYS5_SEND_FILE_PROPERTIES（:543-567）：见 4.3。成功 → u32_upgrade_file_offset = 8 并进入 SEND_UPGRADE_FILE；失败 5 次 → UPGRADE_END。
• SENERGYS5_SEND_UPGRADE_FILE（:569-668）：见 4.4。
• SENERGYS5_UPGRADE_END（:670-717）：见 4.5。default（:719-724）把未知状态强制收敛到 UPGRADE_END。

4.2 帧格式与收发时序

阶段一 ENTER_BOOT（8 字节，无校验字段）

偏移  0     1     2        3     4     5     6     7
    0x01  0xA0  对象码  0x33  0x77  0x99  口令H 口令L
主机:          0x01                      0x97  0xBA   期望应答 0x55
从机:          0x02                      0x97  0xFE   期望应答 0x56
DCDC:          0x05                      0x96  0x8A   期望应答 0x62

发送长度 8（:500），应答码取 u8_upgrade_buf[8]。帧内无长度域、无 CRC，靠固定引导字 + 口令对做合法性判断。

阶段二 SHAKE_HANDS（1 字节）：仅发 u8_upgrade_buf[8]，即把阶段一"预留"的应答码作为握手字节真正发出（:522），等待 0xA5。

阶段三 SEND_FILE_PROPERTIES（4 + 4 字节，两段之间有 200 ms 静默）

:344-349 从 u8_upgrade_addr 起读 8 字节到 u8_upgrade_buf[0..7]（固件头，含义未文档化）；:351 以大端解析 buf[4..7] 为 u32_upgradr_file_size；:352 得 u32_upgradr_block_count = file_size / 2048（整除）。随后 :354 发 buf[0..3]、OSTimeDlyHMSM(0,0,0,200)、:362 发 buf[4..7]（即文件长度），最后等 0xA5，超时 105000 ms（:368，注释"将 15s 超时，改成 105S"，说明逆变器写 Flash 元信息耗时很长）。

阶段四 SEND_UPGRADE_FILE（每块 0/2 + 2048 + 4 字节）

1. senergys5_fill_dsp_upgrade_data()（:588）准备 2 KB 数据与校验和。
2. 仅当 get_inverter_sub() 为 SUB_S5_II 或 SUB_M10（:596），先发 2 字节 0x08 0x00（=2048，大端）并等 0xA5——这是"本块长度"命令；SUB_S5 不发。
3. 发 2048 字节原始数据（:618，不经 senergys5_upgrade_code_handle，即发完不等应答）。
4. 发 4 字节大端累加校验和并等 0xA5（:637）。
5. 三步全部成功（err_count == 0）才 OSTimeDlyHMSM(0,0,0,200)、offset += 2048、send_block_count++（:662-667）。

超时/重试：发送层 usart2_send_data(..., 4000) 为 4000 ms（:95）；senergys5_upgrade_code_handle 的等待为 2000 ms（:317）；每阶段连续失败 5 次即放弃并置 UPGRADE_END。注意 u8_upgradr_err_count 是跨阶段共用的一个计数器，只有成功路径才清零，失败路径保留累加。

4.3 校验和计算（senergys5_fill_dsp_upgrade_data，:384-416）

l_u16_data_len = (offset + 2048 >= file_len) ? (file_len - offset) : 2048   // :392-399
l_addr_temp    = u8_upgrade_addr + offset                                   // :403
u32_check_code = Σ buf[i]  (i = 0..data_len-1，字节无符号累加进 u32)         // :410-414

结果按大端拆成 4 字节存 s_temp_buf（:591-594）。关键点：u32_check_code 只累加从 SDRAM 真实读到的 data_len 个字节，0xFF 填充部分不参与求和。

4.4 块循环的终止条件

:574 的判断是 u32_send_block_count == u32_upgradr_block_count。因为 u32_upgradr_block_count 是整除结果，当文件长度不是 2048 的整数倍时，最后一个不满 2048 的块永远不会被发送（send_block_count 只能取到整除值）。终止时 :576-584 清零 offset 与 send_block_count、状态置 UPGRADE_END，并记录 s_u32_query_inv_ver_tick = OSTimeGet() 作为版本回读的起算点。

4.5 收尾与版本回读（SENERGYS5_UPGRADE_END，:670-717）

memset 后 upgrade_status 归 0 = ENTER_BOOT，因此所有复位路径都自动回到状态机入口；下一次 ENTER_BOOT 发现三 flag 全 FALSE 就置 UPGRADE_END 返回，形成稳定空闲态。

4.6 与 uCOS-II 任务/时序的配合

• 驱动者：task_inverter（inverter.c:1045，周期 80 ms，inverter.c:1188）。同一循环内先 OSFlagPend(g_t_fast_dispatch_flag, PEND_LOGIC_CALCULATE_DONE, ..., 20, &err)，再调 senergys5_inverter_comm()（set_comm_usart_s5.c:6199）。因此升级流程与 EMS 主调度共享 80 ms 节拍。
• 升级期间旁路正常通信：set_comm_usart_s5.c:6201 一旦 senergys5_get_inv_upgrade_flag() 或 senergys5_get_dcdc_start_upgrade_flag() 为真，就只跑升级状态机，并把运行模式置 cUpdateMaster / cUpdateSlave / cUpdateArm（:6213-6227），同时清故障/告警位与通信失联标志（:6204-6209）。
• 无信号量/消息邮箱：本文件不与 uCOS-II 同步对象交互，全部靠 OSTimeGet() 比较 (:123、:676) 与 OSTimeDlyHMSM(0,0,0,50/200)（:139/146/360/664）做阻塞等待——即同步式串口轮询。senergys5_upgrade_recv_mdsp 内部是死循环 + tick 超时，单次最长可阻塞 timeout 毫秒（文件属性阶段实测可达 105 s），期间 task_inverter 整体被占用。
• tick 即毫秒（OSTimeGet() 差值直接与 10*1000、2000、4000 等毫秒常量比较）。

4.7 关键全局变量的读写关系

5. 对外接口

5.1 本文件导出

5.2 本文件调用或引用的外部符号

6. 依赖关系

依赖（本文件 :13-21 的 include）

• inverter.h（get_inverter_sub、SUB_S5_II、SUB_M10、类型定义）
• set_upgrade_s5.h（本文件的接口与上下文结构体）
• upd_download.h（get_length_file_updating、Set/Get_Status_Is_Updated_From_Server）
• inv_download.h（is_inverter_firm_download_finished）
• server.h（ENUpdateType 与 UPDT_INV1/2/3、g_u8_fw_sdram1/2）
• sdram.h（SDRAM_SENERGYS5_UPGRADE_INFO_ADDR）
• usart2.h（UART2 收发）
• hex_file_parse.h、set_comm_can.h：已 include 但本文件未出现其任何符号（残留 include，见 7.6）

被依赖

• midware/inverter/set/set_comm_usart_s5.c（升级触发、单步驱动、模式切换、DCDC 下电标记）
• midware/inverter/inverter.c（inverter_read_upgrade_flag_master/slave/arm、inverter_read_upgrade_percent_master/slave/arm 六个聚合出口，:3812/3847/3882/3917/3976/4003）
• 再往上是 hmi / net 通过 inverter.h 的上述接口消费进度（本文件不直接对外）

7. 备注与风险点

1. memset(s_senergys5_upgrade_info.u8_upgrade_buf, 0xFF, sizeof(SENERGYS5_INV_BLOCK_SIZE));（:409）填错长度。SENERGYS5_INV_BLOCK_SIZE 是整型常量 2048，sizeof(int) == 4，所以这条语句只把前 4 个字节填成 0xFF，而不是 2048 字节（应写 sizeof(u8_upgrade_buf) 或直接 SENERGYS5_INV_BLOCK_SIZE）。后果：末块不足 2048 字节时，剩余字节是上一块遗留的旧数据而非 0xFF 填充，而校验和又只累加真实读到的字节，因此填充区内容与校验和不一致，逆变器端收到的尾部数据是脏的。本文件其它地方（:576）用的是 sizeof(s_temp_buf)，写法不统一。
2. 末块可能被整体丢弃：u32_upgradr_block_count = file_size / 2048（:352）为整除，而循环终止条件是块计数相等（:574）。文件长度非 2048 整数倍时，最后那不足 2048 字节的一段永远不会发出，只依赖逆变器端容忍缺尾。
3. ENTER_BOOT 失败 5 次后"越级"进入 SHAKE_HANDS（:509-514）。此时阶段一并未成功、对象口令也没有被逆变器确认，但仍然跳过重试直接握手；与其它三个阶段的"失败 5 次即 UPGRADE_END"策略不一致。若保留意图是"有些固件进 Boot 后不回 0x55 而直接能握手"，应在注释中说明。
4. SEND_FILE_PROPERTIES 失败 5 次进入 UPGRADE_END 时没有复位 u32_upgrade_file_offset / u32_send_block_count（:556-565）。这些残值会留在被固定地址放置的 s_senergys5_upgrade_info 里；主机升级失败后 UPGRADE_END 若回读版本成功会回到 ENTER_BOOT 接着升从机，而进入 SEND_UPGRADE_FILE 时只重置了 offset（:551）、没有重置 send_block_count。当从机文件块数与残值巧合相等时（:574）会直接判定"已发完"，把从机当成升级成功——这是一个静默失败路径。
5. 百分比函数存在除零风险：senergys5_read_upgrade_percent_master/slave/arm（:228/260/292）都用 offset*100 / u32_upgrade_file_len，而 u32_upgrade_file_len 来自 get_length_file_updating()（服务器下发值）。若对象已选中但长度仍为 0（服务器未给出长度或下载流程未更新），就是整数除零。
6. hex_file_parse.h、set_comm_can.h 两个 include（:17、:21）在本文件中完全未使用：无 hex_parse、无任何 CAN 符号引用，属复制自同类文件的残留。
7. :577 有一行被注释掉的收尾命令 // l_u8_res = senergys5_upgrade_code_handle(s_temp_buf,2,SENERGYS5_INV_REPLY_CODE);，而 :576 仍在 memset(s_temp_buf, ...)，说明"发完块后的 2 字节结束命令"被中途去掉，是版本遗留痕迹。
8. 大量魔法数字内联在函数体里（:451-489 的引导字与口令、:434-435 的 0x08/0x00、:317 的 2000、:368 的 105000、:676 的 10*1000、:691 的 12 次），协议字典没有以宏形式沉淀在 set_upgrade_s5.h；头文件里反而留着零引用的 SENERGYS5_INV_UPDATE_SIZE（set_upgrade_s5.h:19）。
9. u8_upgrade_addr 是非 const 裸指针且被写进固定 SDRAM 地址的结构体：指针值跨软复位保留，若固件版本变化导致 SDRAM 分区调整，复位后会指向错误区域；结构体本身也没有 magic/version 字段做布局校验（见 set_upgrade_s5.h.md 第 7 节）。
10. 阻塞式等待与任务实时性：senergys5_upgrade_recv_mdsp（:116）是纯轮询死循环，task_inverter 在其返回前无法做任何事（文件属性阶段最长 105 s）。OSTimeDlyHMSM(...,50) 只提供 50 ms 粒度的让步，期间 usart2_read_data_async() 会丢弃任何不等于 reply_code 的字节——若逆变器应答含多字节或先发干扰字节，会直接误判为超时。
11. DCDC 分支的 u8_set_dcdc_upgrade_on_flag = TRUE（:708）实际会被立即清掉：紧随其后的公共尾部判断（:711）读的是刚被 memset 清零的主/从标志，因此恒成立，:715 的第二次 memset 把刚置的标记又清零。也就是说"ARM 升级完成后强制逆变器下电"这一标记在 DCDC 路径下从未真正保持为 TRUE（该标记的消费点在 set_comm_usart_s5.c:2831）。疑似漏把该标记移到公共尾部之后。
12. extern 声明重复：:28 又声明了一遍 senergys5_query_inv_update_versions_info，而 set_comm_usart_s5.h:829 已有声明；若两处签名将来不同步会引发隐蔽错误。