拿到一颗完全空白的 SigmaStar SSC335 芯片，第一次上电后串口一点反应都没有，屏幕上没有任何打印信息，这时候不要慌，不是板子坏了，而是 Flash 里还没有任何可执行代码。SSC335 这类方案和 PC 不一样，处理器上电后必须从外部 SPI NOR Flash、SPI NAND、eMMC 或 SD 卡等介质读取启动镜像，空片没有任何启动代码，自然不会有任何输出。这时候就需要用 SigmaStar 官方的 Flash_Tool，通过串口把引导程序、内核、文件系统等原始数据写入 Flash。这篇博文就把我实际烧写 SSC335 空片的完整流程、工具配置、避坑经验一次讲清楚，适合刚接触 SigmaStar 方案、手里正拿着空片或者不小心把 Flash 擦光了的朋友参考。

我先说明一下我这边的基础情况：开发板主控是 SSC335，核心板外挂 16MB SPI NOR Flash，本次烧写用的镜像文件是 release 包里的 spi 烧写镜像。后续涉及具体路径和文件名的部分，我会按常见目录结构写，大家对照自己拿到的 SDK 包做调整就行。

1. 为什么空片绕不开 Flash_Tool

1.1 从启动链路理解烧写必要性

SSC335 的生命周期里，最初始的状态就是芯片内部 Boot ROM 先运行，它根据 chip boot pin 的上下拉配置，决定从哪个外设加载下一级启动代码。空片意味着 SPI NOR Flash 全 0xFF，Boot ROM 读不到任何有效头部信息，更别说后续的 uboot、kernel 了。此时整颗芯片就像一台没有装操作系统的裸机，除了能通过调试串口响应一点最基本的下载协议之外，什么也做不了。

那为什么非要用 Flash_Tool，而不是直接拿烧录器烧？如果你的量产规模很大、板子已经焊好并且要批量灌程序，直接用离线烧录器 + 烧录座是效率最高的。但是对于开发阶段、样板阶段，或者只有一两片板子要救砖的场景，Flash_Tool 不需要拆芯片，不需要额外买烧录座，只要一条 USB 转 TTL 串口线就能搞定。更关键的是，SSC335 在空片状态下，Boot ROM 已经内置了通过 UART 接收数据的下载协议，Flash_Tool 正是利用这个协议把数据灌进 Flash 的。这个能力其他很多 IPC 方案也有，但 SigmaStar 的这套实现非常稳定，只要串口电平正确、boot 模式选对，烧写成功率相当高。

1.2 什么时候必须走 Flash_Tool

我把这些情况归了一下类，供大家参考：

• 全新板卡首次贴片回来，Flash 是空的，没有任何固件，必须先用 Flash_Tool 灌入第一版镜像。
• 开发过程中把 Flash 里数据擦坏了，或者修改了 uboot 环境变量、分区表导致无法正常启动，且 uboot 已经进不去、tftp 下载功能用不了，这时候只能回到最底层用 Flash_Tool 重烧。
• 误操作把 boot1 区域清掉，导致 Boot ROM 找不到合法的启动头部，SD 卡启动和 USB 下载功能没有预先配置或者不可用。
• 个别 Flash 芯片型号或参数设置错误，导致在系统内无法正常挂载和写入，需要重新擦除并完整格式化。

还有一类情况要提醒一下：如果你的板子当前的 uboot 还能跑，只是内核或文件系统启动异常，优先考虑在 uboot 命令行里用串口传文件、tftp、fatload、sf erase、sf write 等方式更新，这样做效率高，而且可以利用已有的启动链路。只有 uboot 完全不可用或 Flash 全空的时候，才需要动用 Flash_Tool 做最底层烧写。分清这两个场景能帮你省很多时间。

2. 烧写前的环境准备与硬件连接

2.1 必要物料和工具清单

我在实际开发中准备的东西如下：

这些物料里，最容易出问题的就是 USB 转 TTL 模块的电平。SSC335 的 UART0 引脚是 3.3V TTL 电平，不能用 RS232 电平的串口直接连，更不能把 5V 电平的 TX 直接接到芯片 RX 引脚上，长时间使用可能损坏主控的 IO。建议先用万用表量一下模块的 VCC 和 TX 输出电平，确认是 3.3V 再接线。

2.2 串口引脚定义与连接方法

SSC335 板卡上一般会引出 UART0 的调试串口，常见引脚标识有 TXD、RXD、GND。连接时要注意交叉连接：板卡的 TXD 接模块的 RXD，板卡的 RXD 接模块的 TXD，GND 接 GND。很多人第一次烧写失败，就是在这里把 TX 和 RX 接反了，或者忘记共地。

需要重点强调的是，极性搞错不会损坏硬件，但会导致烧写工具无法与 Boot ROM 通信，表现为 Flash_Tool 一直卡在“连接中”，或者串口终端完全看不到打印信息。所以我每次新的板卡到手，都先不急着烧写，先把串口工具打开，接好线之后给板卡上电，如果能正常看到 Boot ROM 打印的版本信息或 uboot 启动日志，就说明串口线路基本通了，再开始烧写流程。如果看不到任何打印，我会优先检查 TX/RX 是否接反、模块引脚是否虚焊、GND 是否连接，而不是急着怀疑工具或固件有问题。

2.3 Boot 模式确认

SSC335 上电时通过 boot pin 的电平状态决定启动介质。大部分公板方案会通过拨码开关或电阻配置 SPI NOR 启动，开发板上通常会有丝印标注。举个例子，拨码开关拨到 SPI NOR 挡位时，Boot ROM 会去读 SPI NOR；拨到 UART 下载挡位时，Boot ROM 会停留在等待外部下载的状态。具体哪个拨法是哪个模式，不同板卡设计不一样，大家务必翻一下自己板卡的原理图或者硬件手册。

这里有一个容易踩的坑：有些人觉得 Flash_Tool 既然是通过串口下载，那 boot 模式随便拨一拨就行，其实不对。Flash_Tool 能工作，恰恰依赖 Boot ROM 正确初始化了 UART 并进入下载等待状态，而这通常要求芯片处于“UART 下载模式”或“自动探测模式”。如果你的板卡上电后 Boot ROM 选择了从 SPI NOR 启动（哪怕 Flash 是空的），它不会停留在 UART 下载状态，或者只会短暂停留后继续执行，工具端表现就是连接不稳定、时不时失败。所以动手之前，先看硬件手册确认正确的 boot 拨码，宁可多花两分钟确认，也不要反复试错浪费时间。

3. Flash_Tool 配置与烧写完整步骤

3.1 软件安装与串口驱动确认

SigmaStar Flash_Tool 一般是绿色免安装的压缩包，解压后直接运行主程序。但有一个前置条件：USB 转 TTL 模块的驱动必须装好，并在设备管理器里能看到对应的 COM 口号。CH340 基本是免驱的，CP2102 偶尔需要手动装一下 Silicon Labs 的驱动，FT232 如果要兼容旧系统可能需要关掉驱动签名校验。总之，打开设备管理器，插拔模块，确认 COM 号不会跳动，这一步就算过了。

这里再补充一个细节：Flash_Tool 本身不要去负责板卡供电。如果板卡的供电由 USB 转 TTL 模块提供，模块输出的电流可能不够，尤其烧写过程中 Flash 擦写瞬间电流会有波动，容易导致复位或烧写中断。我用的开发板是独立 Type-C 口供电，USB 转 TTL 模块只接三根线（TX、RX、GND），不接 VCC，这样就避免了模块供电能力不足的问题。

3.2 打开 Flash_Tool 并选择芯片平台

工具打开后，第一步是选择平台和芯片型号。SSC335 属于 SigmaStar 的 SSC33x 系列，在列表里选择对应型号，再选 Flash 类型。注意，Flash_Tool 的版本不同，界面布局会有差异，但核心配置项都类似。

我这里以 SPI NOR 为例说明配置要素：

有些工具版本在烧写前会有“硬件初始化”或“下载 DDR 初始化代码”的过程，这是因为 Boot ROM 需要先把 DDR 初始化代码下载到内存中，再做数据搬移和 Flash 擦写。不要认为这是多余的步骤，它是 SigmaStar 这套方案能烧录各种外部 Flash 的基础机制。工具会先把一个极小的初始化代码加载到芯片内部 RAM 或 DDR，让它接管后续的 Flash 操作。这也解释了为什么连接时要严格遵循工具的时序提示，不要提前上电也不要手动复位乱按。

3.3 加载烧写镜像与分区配置

拿到 SDK release 包之后，通常会有一个 image 目录，里面包含不同用途的镜像。常见的分区镜像包括：

• boot1 / boot2：SigmaStar 方案的二级引导，属于 Boot ROM 之后加载的第一份用户代码，负责初始化 DDR、加载 uboot。
• uboot：主引导程序，提供环境变量、内核引导、网络下载等功能。
• kernel：Linux 内核镜像。
• rootfs：根文件系统镜像。
• 部分方案还会有mcu / sensor 校准数据等专有分区。

Flash_Tool 的配置界面里，通常会把这些分区以列表形式展示，每一项对应一段起始地址和数据来源。不同 SDK 的默认分区表可能不一样，我自己习惯的做法是：优先使用 release 包里现成的分区配置文件，不要手动修改地址。如果确实要自己建配置，一定要对照 SDK 的 partitions 表来，避免地址重叠导致烧完启动不了。比如 boot1 在 SPI NOR 里通常放在 0x0 地址，uboot 在 0x40000，kernel 在 0x200000 等，这些地址写错了，轻则启动异常，重则把正确启动代码覆盖掉。

文件加载路径上，有的工具要求逐个分区添加镜像，有的支持一整份打包镜像。操作逻辑都差不多，逐个选择，点击加载，确认列表里每个分区的源文件对应正确。我有时会遇到误把 kernel 镜像放在 boot 分区里的情况，这会导致烧录成功但是启动完全无打印，排查了老半天最后发现是分区映射错了，所以每一步核对分区列表真的很有必要。

3.4 连接设备并开始烧写

配置完成后，操作顺序是这样的：

1. 先把 USB 转 TTL 模块插入电脑，确认设备管理器里的 COM 口号。
2. 打开 Flash_Tool，在配置界面选好串口号、波特率，加载好全部镜像。
3. 将开发板断电，确认 boot 拨码在正确挡位。
4. 点击 Flash_Tool 的“开始烧写”或“连接”按钮，工具会提示等待设备上电。
5. 给开发板上电，工具开始与 Boot ROM 通信，下载初始化代码，然后自动擦除、写入、校验。

这个过程里最关键的是时序：先点开始，再上电。SigmaStar Boot ROM 的上电探测窗口一般很短，如果你先上电再点开始，Boot ROM 可能已经尝试从未初始化的 Flash 启动并卡死，无法回到 UART 下载状态。当然也有工具支持特殊握手，但为了稳妥，我每次都是严格按“先点烧写，后上电”的顺序操作。如果失败，就断电重新点烧写再上电，不要只按复位键而不彻底断电。

开始烧写后，工具界面会显示进度条和当前操作阶段，比如擦除、下载、校验。SPI NOR 16MB 的镜像，用 115200 波特率传输会比较煎熬，可能要十几分钟甚至更久；把传输波特率调高到 921600 后通常能缩短到两分钟以内。我用 CH340 模块 921600 波特率烧写 16MB 镜像，整个过程大约 90 秒左右，表现稳定。如果你的线材较长或模块质量一般，高波特率下容易出错，那就退回 460800 或者 115200，稳定优先。

3.5 烧写完成后的首次启动验证

烧写过程提示成功后，Flash_Tool 的任务还没完全结束，还需要验证一下启动状态。操作顺序是：先关闭 Flash_Tool 的烧写连接，断开板卡电源，然后把 boot 拨码切回从 SPI NOR 启动的挡位，重新上电。如果镜像正确、分区正确、Flash 型号正确，串口终端里就能看到 uboot 的启动日志，引导内核、挂载文件系统都正常，这次烧写才算真正成功。

我见过有人在 Flash_Tool 提示成功后直接热插拔 USB 转 TTL 模块，导致板卡复位异常，又进不了系统，然后以为烧写失败来回折腾。其实极大概率是操作时序问题，断电重新上电一般就能解决。所以烧写成功后的第一次启动验证，我建议养成固定习惯：完全断电，再上电，不要偷懒直接按复位。

4. 常见问题与排查技巧实录

4.1 串口无打印或连接超时

这是空片烧写里最普遍的问题，我已经遇到太多次了。排查顺序我从高到低列一下：

• TX/RX 接反：交换两线重新试，或者用串口助手回环测试模块本身是否正常。
• GND 未共地：USB 转 TTL 模块和板卡必须共地，否则信号会有电位差，导致通信时好时坏。
• boot 模式拨错：确认拨码是否处于 UART 下载模式，不同板卡定义不同。
• USB 转 TTL 模块输出电压异常：用万用表量模块 TX 引脚的静态电平，正常空闲时应该是 3.3V 附近，不能是 0V 或者 5V。
• 板卡没有真正进入下载状态：上电前按住板卡上的某个下载按键，或者上电瞬间观察串口是否有 Boot ROM 打印信息，不同板卡的进入方式不同。

我还遇到过一个比较隐蔽的情况：USB 转 TTL 模块的 TX 引脚因为之前接错过 5V 已经损坏，静态电平不对，换上另一个模块立刻就好了。所以手边多备一两个模块，排查起来会快很多。

4.2 烧写到一半卡住或校验失败

高波特率下传输数据出错是最常见的原因，尤其线材过长、模块质量一般、或者电脑 USB 口供电不稳。我的处理策略是：

• 先把波特率降到 460800 或 115200 重试，如果问题消失，就是传输稳定性问题。
• 换一条更短的杜邦线，线长控制在 15cm 以内。
• 如果用的是笔记本，尝试换一个 USB 口，尤其是不要插在 USB Hub 上。
• 关闭电脑上其他占用串口的软件，避免串口被抢占导致丢数据。

如果是卡在擦除或写入阶段，另一个常见原因是 Flash 型号选错。工具按所选型号的参数去发擦除和写入命令，型号不对轻则操作超时，重则损坏 Flash 的某些状态寄存器。如果工具支持自动识别 Flash 型号，优先用自动识别，不要凭印象选。

4.3 烧录成功但启动无打印

这种情况比烧写失败更让人抓狂，因为工具已经提示成功了，但板卡就是起不来。我建议按以下顺序排查：

• 确认 boot 拨码是否切回 SPI NOR 启动模式，这是最高频的疏漏。
• 确认分区地址和镜像对应关系是否正确，尤其是 boot1、uboot、kernel 的位置。
• 确认 Flash 型号与工具选择的是否一致，如果实际 Flash 是 W25Q128，工具里选了 W25Q64，写进去的地址范围可能错位，导致 Boot ROM 读不到有效头部。
• 确认串口终端连接的还是同一个 UART0，有些板卡还有第二路 UART 用于外设通信。
• 仔细看串口是否有极短乱码或重复打印，如果有，可能是 uboot 启动阶段 DDR 初始化失败，或时钟配置不对，需要检查 SDK 默认配置是否与板卡匹配。

根据我个人的经验，“烧录成功但无打印”里至少有一半是 boot 拨码没切回正确模式，或者工具里 Flash 型号没选对。这类问题不需要急着动硬件，先把配置项逐一核对清楚。

4.4 工具识别不到串口

Windows 下可能显示为“USB-SERIAL CH340”之类的设备，但有时会出现黄色感叹号。处理方法一般是重新拔插模块、更新驱动，或者换一个 USB 口。还有一点，个别精简版系统的驱动库不完整，CP2102 和 FT232 这类芯片需要手动安装驱动。如果设备管理器里能看到 COM 口但还是连不上，检查是否有其他程序占用，比如串口终端软件还开着，COM 口被独占，Flash_Tool 自然打不开。关掉其他占用程序再试一次，很多问题就这么解决了。

4.5 烧写速度慢到无法接受

115200 波特率下烧写 16MB 镜像确实折磨人，这时候可以把传输波特率调高到 921600，常见 USB 转 TTL 模块都能支持。需要注意的是一次性把速率调太高可能不稳定，我一般从 460800 起步，稳定后再尝试 921600。对于 SPI NOR 这类小容量 Flash，这个速率已经足够快了。如果你要烧的是 eMMC 或大容量 NAND，建议优先考虑 USB 烧录、TF 卡升级等方式，不要纯靠串口硬怼。

5. 实操心得与扩展建议

5.1 备份一切能备份的东西

烧写空片之前，如果能找到同一批次、同一型号、已经能正常工作的板卡，我强烈建议先把它 Flash 里的完整内容读出来备份。SigmaStar Flash_Tool 通常也支持读取功能，或者你可以在 uboot 里把完整镜像 dump 出来。有了这份备份，后续不管是误擦除还是想对比出厂配置，都有底牌可翻。

读出来之后把镜像文件和对应的板卡型号、Flash 型号、烧写日期、备注信息一并记录好。我吃过一次亏，当时没做备注，过了一个月看到一堆 bin 文件完全分不清哪个对应哪块板卡，只好拿回开发环境重新编译，浪费了不少时间。标签和归档这件事，看起来简单，但真到救急的时候特别有用。

5.2 从 Flash_Tool 到量产烧录的过渡

开发阶段用 Flash_Tool 没问题，但到了小批量或量产阶段，效率就成了刚需。SigmaStar 方案的量产一般有两种路径：一是用离线烧录器配烧录座，先把镜像烧进 Flash 再贴片；二是板卡贴片后通过 UART 模式用 PC 端工具灌入，也就是 Flash_Tool 的自动化模式。后者速度和稳定性都依赖串口和电脑环境，适合小批量；前者适合大批量。如果你是从开发转量产，建议尽早评估哪种方式更合适，不要等到产线上拿 Flash_Tool 一台一台慢慢烧，那样效率太低。

5.3 烧写过程中保持耐心与记录

嵌入式开发里，烧写空片这件事本身并不复杂，但涉及到的细节实在太多。我每一次烧写，都会把操作步骤、工具版本、固件版本、Flash 型号、拨码状态、串口参数、异常现象这些信息记录在一个简单的笔记里。看起来有点啰嗦，但在遇到诡异问题需要复现时，这套记录能帮你快速定位是固件变化、工具版本变化还是硬件批次差异导致的。技术工作很多时候不是比谁懂得多，而是比谁细心、谁能更快排除变量。就算今天烧的是同一块板卡，隔了几个月再拿起来，有记录和没记录完全是两种体验。

最后再补充一个个人习惯：烧写完成后，不要急着把 USB 转 TTL 线拔掉，先断电，再拨码，再上电，确认启动日志正常后再拔线。这样每次烧写都能形成一个完整的闭环，避免“烧完就完了，后来发现根本没起来”的尴尬。这套流程我在 SSC335 和其他 SigmaStar 芯片上重复了无数次，按这个节奏走，基本没有返工过。