小鸿镜像烧录实录 + 启动日志深度解析（三部曲完结篇）

前面两篇我们搞定了开发环境搭建和源码编译，这篇是三部曲最后一环：把编译出来的镜像烧到小鸿开发板上，让它真正跑起来。

烧录本身不难，难的是看懂串口日志——日志里藏着系统启动的全部秘密。这篇文章前半部分讲烧录操作，后半部分带你逐段解析启动日志，从早期初始化到 WiFi 自动联网拿 IP，一条不落。

💡 系列回顾：

• 第一篇：[Ubuntu + Windows 双系统远程开发环境搭建指南]
• 第二篇：[小鸿源码编译完整指南]

---

一、烧录前准备

烧录之前，确认下面这些条件都满足了：

前提条件	说明
源码已编译完成	镜像文件在 ~/xiaohong/out/xiaohong/xiaohong/ws63-liteos-app 目录下
Windows 侧工具齐备	BurnTool 烧录工具、USB 驱动、串口终端工具（如 UartAssist）
USB 线缆已连接	小鸿通过 USB 连到 Windows 设备
Samba 共享已映射	能在 Windows 下直接访问 Ubuntu 的编译产物目录

💡 这里就用到了第一篇配的 Samba 共享——编译产物在 Ubuntu 上，但烧录工具跑在 Windows 上，映射网络驱动器正好把两边打通。前面埋的坑现在填上了 😎。

---

二、BurnTool 烧录步骤

2.1 设置 BurnTool 参数

打开 BurnTool 工具，设置参数：

• 根据实际情况选择 COM 口（设备管理器里能看到小鸿对应的串口号）
• 勾选 Auto burn（自动烧录）
• 勾选 Auto disconnect（烧完自动断开）

2.2 选择烧写文件

单击 Select file，在映射的网络驱动器里找到编译产物目录，选中烧写文件：

2.3 连接并触发复位

这一步是整个烧录流程的关键，注意看：

步骤一： 确认 COM 口选择正确，单击 Connect 按钮。此时 BurnTool 中间提示框会出现 Connecting... 字样。

步骤二： 在出现 Connecting... 的同时，按下小鸿设备正上方的左右两个按键（音量加 + 和音量减 - 键，按键不分先后顺序），然后立即松开。

这一下是对 WS63 芯片进行复位，复位后自动进入烧录模式，烧录流程随即启动。

步骤三： 烧录开始后，BurnTool 下方的控制台区域会刷出烧录过程的打印信息。等待进度条走完，控制台打印 Execution Successful，烧录完成。

⚠️ 复位操作要点： 时机很重要！必须在 BurnTool 显示 Connecting... 时同时按住音量 + 和音量 - 两个键，然后立即松开。如果烧录没有启动，别慌，重新点一次 Connect 再按一遍就行。我自己试的时候也是第二次才成功的 😅。

---

三、开机启动与日志查看

烧录完成后设备会自动重启。想看到启动日志，需要用串口终端工具。

3.1 配置串口参数

打开串口终端工具（我用的是 UartAssist），按下表配置：

参数	值
串口号	小鸿对应的 COM 口
波特率	115200
校验位	NONE
数据位	8
停止位	1
流控制	NONE

配置好之后点「打开」按钮：

3.2 触发重启并查看日志

同时按下小鸿顶部的左右两个按键（音量 + 和音量 -），小鸿重新启动，串口调试助手的数据日志窗口就会开始滚动输出启动日志：

---

四、小鸿启动日志深度解析

这部分是本文精华。拿到一大坨日志不知道从哪看起？我按时间线把它拆成了 11 个阶段，逐段解读。

4.1 日志概览

先看全流程时间线，从上电到联网成功，全程不到 7 秒：

时间点	阶段	结果
11:19:00.509	早期初始化	正常
11:19:00.571	板级/外设/LCD/射频校准	正常
11:19:00.698	WiFi 驱动与 VAP 初始化	正常
11:19:01.757	显示收到 WiFi 状态更新	正常
11:19:01.836	STA 开始扫描	正常
11:19:03.493	扫描完成，发现 22 个 AP，选定 XXX-2.4G	正常
11:19:04.061	认证/关联/EAPOL 握手	正常
11:19:04.254	连接成功，开始 DHCP	正常
11:19:07.339	DHCP 获取 IP 192.168.77.30，STA 连接完成	成功

✅ 结论先行： 系统从串口、文件系统、板级、WiFi 任务、显示、射频到自动连上路由器并拿到 IP，全流程正常。这是一次完整、健康的启动。

4.2 阶段一：早期初始化

APP|dbg uart init ok.
APP|SDK Version: 1.10.106
[UPG] init OK!
APP|init_sle_mac failed!
APP|mac_addr:0xde,0x 0,0x73,0x4e,0x**,0x**,
xo_trim_temp_comp val:0 0
los_at_plt_cmd_register EXCUTE
APP|=========FS MOUNT=========
APP|=========FS READY=========

逐行解读：

• dbg uart init ok：调试串口初始化成功，后面所有日志都从这个串口输出
• SDK Version: 1.10.106：当前运行的 SDK 版本
• [UPG] init OK!：升级（Upgrade）模块初始化完成
• init_sle_mac failed!：⚠️ 看到这个别慌！SLE MAC 没有被写入（NV/工厂区/eFuse 都没有），主 MAC 会用随机值兜底（本次为 0xde,0x00,0x73,0x4e,...），不影响正常使用
• FS MOUNT / FS READY：文件系统挂载成功

4.3 阶段二：系统服务与板级初始化

hilog will init. / hievent init success.
Please implement the interface according to the platform!
cpu 0 entering scheduler
APP|cali_is on
APP|btc open
hiview init success.
adc_port_register_irq succeed: 0
[BoardCfg] spi1_init:   spi1_inited[0->1]
[BoardCfg] uart2_init: uart2_inited[0->1]
[BoardCfg] board_hw_init: hw_inited[0->1]

调度器、校准、蓝牙、hiview、ADC、SPI1、UART2、板级初始化全部成功。

💡 Please implement the interface according to the platform! 这条看着吓人，其实就是某平台接口的占位提示，不影响启动和联网，直接无视。

4.4 阶段三：WiFi 任务与设备初始化

[WiFiTask] -------------------------------
[1302Task] osMessageQueueGet: msg[2]
[RADAR_LOG] radar_timer_init succ
[RADAR_LOG] alg ctrl read from nv [1][2][0][0][1][1][20]
device_main_init: 0!
===hal_initialize_phy===226===
device_module_init:: succ!
lcd_init: st7789
cali_set_cali_mask:old[0x0] -> new[0x1fa2]
fe_rf_initialize
cali_offline_cali_entry enter
cali_set_cali_done_flag:old[0x0] -> new[0x1]
rf cali OK. time cost:22, ret:0

WiFi 任务启动；1302 语音任务收到 msg[2]；雷达、设备主初始化、PHY、设备模块、LCD（st7789 屏）、射频校准全部正常。

重点关注： rf cali OK 表示射频校准通过，这是 WiFi 能正常工作的前提，耗时 22ms。

4.5 阶段四：WiFi 驱动与 VAP 状态

drv_soc_ioctl ioctl_cmd->cmd=7.
drv_soc_ioctl ioctl_cmd->cmd=9.
...
======= state 5 vap 1=========
drv_soc_ioctl ioctl_cmd->cmd=13.
drv_soc_ioctl ioctl_cmd->cmd=35.
drv_soc_ioctl ioctl_cmd->cmd=2. (x6)
drv_soc_ioctl ioctl_cmd->cmd=41.

drv_soc_ioctl 是 WiFi 驱动层与 SoC 的 ioctl 调用，完成能力查询、参数设置、信道/功率等配置。

重点看 state： state 5 vap 1 表示 VAP（虚拟 AP/STA 接口）状态机进入状态 5——STA 接口已就绪，可以开始扫描和连接了。后面还会看到 state 6、7、8、9、11、12 的流转，每个状态对应 WiFi 连接的一个阶段。

4.6 阶段五：显示任务收到 WiFi 状态更新

[LvglTask] osMessageQueueGet: msg[3]

msg[3] 对应 eDisp_WiFi_St_Update（在 disp_driver.h 中枚举值为 3）。

表示 WiFi 任务在「自动连接中」或「已连接」时向显示任务发送了状态更新，界面会刷新 WiFi/Vol/Blk/Bat 或配网/连接结果文案。

💡 小鸿的 UI 是 LVGL 画的，任务间通过消息队列通信——WiFi 任务负责连接，连上后发消息通知显示任务刷新界面，各干各的，解耦很清晰。

4.7 阶段六：STA 扫描

[wifi_sta] connect_to_hotspot: wifi_sta_scan:
drv_soc_ioctl ioctl_cmd->cmd=14.
======= state 6 vap 1=========
...
hmac_single_hal_device_scan_complete:vap[1] time[1533] chan_cnt[13] chan_0[1] back[0] event[6] mode[0]
======= state 7 vap 1=========
Scan::vap[1] find bss_num[22] in regdomain, other bss_num[0]
Srv:756:receive event = 1
Srv:1957:scan_results cnt 22

逐行解读：

• wifi_sta_scan：开始扫描，cmd=14 是扫描相关 ioctl，state 6 表示扫描进行中
• scan_complete：扫描完成，耗时约 1533ms，扫了 13 个信道，发现 22 个 BSS（也就是周围有 22 个 WiFi 热点），state 7 表示扫描结果就绪
• scan_results cnt 22：服务层拿到 22 个扫描结果，供后续选网使用

4.8 阶段七：选定 SSID 并发起连接

[wifi_sta] connect_to_hotspot: wifi_sta_connect[XXX-2.4G]
Srv:find ssid[XXX-2.4G] auth type[3] pairwise[1] ft_flag[0]
drv_soc_ioctl ioctl_cmd->cmd=47. (x3)
drv_soc_ioctl ioctl_cmd->cmd=16.
======= state 8 vap 1=========

逐行解读：

• wifi_sta_connect：从 NV 读取的 SSID 为 XXX-2.4G，与扫描结果匹配后发起连接
• auth type[3]：一般为 WPA2-PSK（或等同）；pairwise[1]：加密套件；ft_flag[0]：无 802.11r 快速切换
• state 8：进入关联/认证阶段

4.9 阶段八：认证与关联

wifi:tx auth seq 1 alg 0 code 0
======= state 9 vap 1=========
wifi:rx auth seq 2 alg 0 code 0
======= state 11 vap 1=========
wifi:tx assoc req
======= state 12 vap 1=========
wifi:rx assoc rsp code 0

逐行解读：

• auth seq 1/2：开放系统认证请求与响应成功
• assoc req / assoc rsp code 0：关联请求与关联响应（成功），STA 已与 AP 关联

4.10 阶段九：WPA2 四次握手（EAPOL）

wifi:rx eapol 1/4
drv_soc_ioctl ioctl_cmd->cmd=6. (多次)
wifi:tx eapol 2/4
wifi:rx eapol 3/4
...
wifi:tx eapol 4/4
drv_soc_ioctl ioctl_cmd->cmd=3.
drv_soc_ioctl ioctl_cmd->cmd=1.
+NOTICE:CONNECTED
Srv:756:receive event = 2
[wifi_sta] wifi_connection_changed: Connected

逐行解读：

• eapol 1/4 ～ 4/4：WPA2 四次握手完成，密钥协商成功
• +NOTICE:CONNECTED：驱动/服务层上报「已连接」事件
• wifi_connection_changed: Connected：应用层（net_wifi_station.c 回调）收到连接成功，WiFi 链路层已 up

💡 四次握手（EAPOL 4-way handshake）是 WPA2 加密的核心环节：AP 和 STA 通过四次报文交互协商出单播加密密钥，握手完成才算真正「安全地」连上网。

4.11 阶段十：DHCP 与 IP 获取

[wifi_sta] connect_to_hotspot: DHCP start ...
...
[wifi_sta] connect_to_hotspot: netifapi_dhcp_is_bound OK
server :
    server_id : 192.168.77.1
    mask : 255.255.255.0, 1
    gw : 192.168.77.1
    T0 : 1800
    T1 : 900
    T2 : 1575
clients <1> :
    mac_idx mac             addr            state   lease   tries   rto
    0       de00734ec5c2    192.168.77.30   10      0       1       4
[wifi_sta] connect_to_hotspot: End. STA Connected.

逐行解读：

• netifapi_dhcp_is_bound OK：DHCP 已绑定，设备成功拿到 IP
• 服务器：192.168.77.1，掩码 255.255.255.0，网关 192.168.77.1；租期 T0/T1/T2 为 1800/900/1575 秒
• 客户端：MAC de:00:73:4e:c5:c2（与前面 mac_addr 一致），IP 192.168.77.30，state 10 表示已绑定
• End. STA Connected.：connect_to_hotspot() 正常返回，自动连接流程圆满结束 🎉

4.12 阶段十一：连接成功后的 UI 与语音

[LvglTask] osMessageQueueGet: msg[3]
[1302Task] osMessageQueueGet: msg[8]

逐行解读：

• msg[3]：显示任务再次收到 eDisp_WiFi_St_Update，界面显示「WiFi 连接成功！」并更新状态栏
• msg[8]：1302 任务收到 eAud_NetConned（网络已连接），可以播放「已连网」等语音提示

至此，从芯片复位到屏幕显示「连接成功」+ 语音播报，整条链路全部跑通。

---

五、烧录常见问题与踩坑记录

5.1 BurnTool 一直显示 Connecting… 不开始烧录

复位按键的时机不对。必须是在 Connecting... 出现的同时按下音量 + 和 -，然后立即松开。多试几次找手感，或者重新点 Connect 重来。

5.2 找不到 COM 口 / COM 口列表是空的

• 检查 USB 线是否插好（有些线是纯充电线，不带数据）
• 检查 USB 驱动是否安装成功，设备管理器里看有没有黄色感叹号
• 换个 USB 口试试

5.3 烧录中途中断 / 失败

• 换一根质量好的 USB 线（短的更好）
• 换 USB 口，尽量别用前置面板的口
• 重新走一遍 Connect + 复位流程

5.4 串口看不到日志

• 确认串口参数：波特率 115200，校验 NONE，数据位 8，停止位 1，流控制 NONE
• 确认选的 COM 口是小鸿对应的那个（不是 BurnTool 占用的口）
• 串口工具要先「打开」再触发重启

5.5 日志里出现 init_sle_mac failed!

前文说过，这是 SLE MAC 未写入，系统已用随机 MAC 兜底，不影响 WiFi 联网等正常功能，可以放心忽略。

---

总结

烧录环节核心就一个动作：Connect 后看到 Connecting... 立刻按音量加减键复位。日志分析环节重点记住 VAP 状态机（state 5 就绪 → 6 扫描 → 7 结果 → 8 关联 → 9/11/12 认证关联 → EAPOL 握手 → DHCP 拿 IP），以后排查 WiFi 连不上是卡在哪一步，对着日志找 state 就行。

📌 本文基于官方开发指南 + 实机烧录验证，日志解读部分结合了 OpenHarmony WiFi 驱动的实现逻辑。有问题欢迎评论区交流，看到日志贴出来一起分析 🔍

最后求个赞 + 收藏 + 关注，三连支持一下博主更新动力！🤝