CY7C68013A C0模式启动：EEPROM固件加载与自动运行指南

1. 先弄清楚 C0 模式到底解决什么问题

1.1 开发模式下你需要反复下载固件的原因

如果你玩过 CY7C68013A 这块 EZ-USB FX2LP 芯片，应该都经历过这种场景：上电后插上 USB 线，电脑识别出一个 04B4:8613 的设备，然后你用 CyConsole 或者 cycfx2prog 把固件下载进去，设备才变成你真正想要的那个 USB 设备。开发阶段这么干没问题，但一旦你要做小批量或者自己做一个独立运行的小工具，总不能每次都打开上位机手动下载固件吧？所以就要考虑“C0 模式启动”——让芯片一上电就自动从外部 EEPROM 里把固件读进来，然后自己跑起来。

CY7C68013A 是一颗内置增强型 8051 内核的 USB 2.0 控制器，芯片内部没有 Flash，代码最终都要放到 RAM 里执行。所谓启动，实际就是谁来把固件从某个存储介质搬运到 RAM 里，再把 8051 的复位释放掉。这块芯片在上电复位以后，片内 ROM 里的 bootloader 会先去检查 I2C 总线，看看有没有接 EEPROM，以及 EEPROM 里的第一个字节是什么。根据这个字节的值，它会决定走 USB 下载、C0 模式还是 C2 模式。你听到的“C0 模式启动”，指的就是 bootloader 在 EEPROM 里读到 0xC0 这个模式字节，然后按照 C0 加载记录，把固件拷贝到内部 RAM 并从 0x0000 地址开始执行。

很多刚接触的人会把 C0 模式理解成一种烧录动作，其实不太准确。C0 模式首先是镜像格式的一块标识，其次才是启动过程。你编译出来的 .hex 不能直接扔进 EEPROM，必须先转换成带有 C0 头部的 .iic 格式，或者用工具加上对应的启动记录，芯片才会认。这个区分特别重要，因为它决定了你排查问题的方向：如果启动失败，你得先确认 EEPROM 里的数据格式是不是对的，而不是一上来就怀疑硬件。

1.2 三种启动路径，C0 是中间那条

我自己习惯把 FX2LP 的启动路径分成三类，方便和同事沟通。第一种是纯 USB 启动，也就是 EEPROM 不存在、为空或者第一个字节不是有效的模式字节时走的路。此时芯片会枚举成一个默认的加载器设备，也就是常见的 04B4:8613，固件完全依赖主机通过 USB vendor request 写到内部 RAM。掉电就没了，适合开发调试。

第二种就是 C0 模式启动。EEPROM 首字节是 0xC0，bootloader 会把后续记录里的固件数据加载到 CY7C68013A 片内 8KB RAM 里，加载完成后启动 8051。这种方式的好处是硬件简单，只需要一颗 I2C EEPROM，不需要外扩存储器，也不需要占用大量 IO 做地址线和数据线。缺点是内部 RAM 只有 8KB，代码加变量加堆栈都挤在里面，程序大了根本放不下。

第三种是 C2 模式启动。EEPROM 首字节是 0xC2，bootloader 会把固件加载到外部 RAM 或者外部存储空间，8051 从外部存储器执行。这种方式可以突破 8KB 限制，但要求你把地址总线、数据总线、控制信号全部接到外部 SRAM 或 Flash 上，占用的 IO 非常多，PCB 布线也复杂很多。FX2LP 的 C2 模式不是默认项目，新手直接上 C2 很容易被时序和映射问题折磨。

从工程角度说，C0 模式是大多数不上复杂操作系统的 FX2LP 项目的最佳平衡点。你只需要一颗 24LC64 或者 24LC128，占两个引脚，成本低，可靠性也不错。

1.3 C0 模式不只是“自动运行”这么简单

深入到应用层，C0 模式还牵扯到 USB 重枚举的问题。很多第一次做 C0 启动的人会以为：只要 EEPROM 烧对了，上电后设备就应该立刻显示成固件里的 VID/PID。但实际上，FX2LP 上电后首先会以一个默认加载器设备的状态出现在 USB 总线上，然后固件在 main 函数里执行到 USB 重枚举那段代码后，设备才会断开再重新连接，最终以固件定义的身份出现。

如果固件里没有做重枚举，或者重枚举之前程序就卡死了，你就会看到一个很误导人的现象：明明 EEPROM 烧进去了，设备却还是 04B4:8613。这个问题我在帮朋友调板子时遇到过不止一次，很多人的第一反应是 EEPROM 没烧进去，于是反复烧录，折腾半天才发现是固件没跑起来。所以后文里我会把验证方法、镜像格式、硬件配置和排查链路都串在一起讲，你可以直接照着步骤做。

2. C0 启动镜像格式：直接烧 .hex 多半要翻车

2.1 0xC0 模式字节是怎么被加载的

FX2LP 的 bootloader 在复位后会把 I2C 总线上挂在地址 0x50 附近的 EEPROM 读一遍，读到的第一个字节就是模式判断依据。如果这个字节是 0xC0，bootloader 就会继续从 EEPROM 里读出一组组加载记录，每一组记录里面包含目标地址、数据长度和实际数据，然后把这些数据写入内部 RAM 的对应位置。全部写完后，8051 从地址 0x0000 开始执行。

这里的“目标地址”正常情况下是内部 RAM 的地址，范围在 0x0000 到 0x1FFF 之间，因为 FX2LP 提供给 8051 使用的内部 RAM 大约是 8KB。如果你生成的镜像里目标地址超出了这个范围，那说明固件格式选错了，或者代码段本身已经超过了 C0 模式能够承载的体积。这个数据搬运过程你也可以在逻辑分析仪上看到：SCL 上会出现连续的 I2C 读操作，数据线上会依次出现 0xC0、地址、长度、数据块。

先不要纠结底层协议里的每个字节要不要手算，核心是你得明白：EEPROM 里的数据不是简单的固件 bin 平铺，而是带加载描述的结构化镜像。直接拿编译器生成的 .hex 往 EEPROM 里写，bootloader 读到的第一个字节大概率不是 0xC0，自然也就不会进入 C0 模式。

2.2 用 hex2bix 或脚本生成 .iic

Cypress 官方工具链里有一个命令行工具叫 hex2bix，专门用来把编译生成的 .hex 转换成适合烧写到 EEPROM 的 .iic 文件。它的关键参数是模式字节，生成 C0 镜像时一般用 0xC0，生成 C2 镜像时用 0xC2。我当时用的命令大致是这样：

hex2bix -i -f 0xC0 -o firmware.iic firmware.hex

参数 -i 表示生成 Intel 格式的 .iic 文件，-f 后面跟的是启动模式字节，-o 指定输出文件名，最后一个参数是编译出来的 hex 文件。执行完后，你可以用十六进制编辑器打开 firmware.iic，看一眼最前面的几个字节。正常情况下应该能看到类似C0 00 00 10 ...这样的结构，其中C0就是模式字节。

如果你不想装官方工具，也可以找一些开源脚本自己拼。网上常见的 make_fx2_fw.py 一类工具，本质就是把编译后的 bin 文件按照加载记录格式切块，然后在每个记录前面加上模式字节、目标地址和长度。我自己写脚本时习惯把每条记录限制在 16 字节左右，这样 EEPROM 写入时不容易出错，调试时看逻辑分析仪也更好追踪。

2.3 手动检查镜像内容

烧录前花一分钟检查镜像内容，能省下很多排查时间。用命令行可以直接看文件头：

xxd firmware.iic | head -n 5

如果第一行不是以c0开头，就要回头检查 hex2bix 的参数或者原始固件的链接地址。另外，还要注意镜像文件的大小。C0 模式内部 RAM 是 8KB，所以整个 .iic 解出来的有效数据体积理论上不应该超过 8KB。如果文件大得离谱，即使是 C0 头部，加载到一半也可能出错。这个检查特别重要，因为我见过有人把一个大固件用 C0 模式烧进去，结果 8051 跑飞，USB 设备反复断开重连，非常难查。

3. 硬件配置与 EEPROM 选择

3.1 EEPROM 型号、容量、地址引脚

C0 模式启动需要一颗标准 I2C 接口的 EEPROM。最常见的型号是 Microchip 的 24LC32A、24LC64、24LC128、24LC256，Atmel 的 AT24C 系列也完全兼容，只是厂商前缀不同。容量选择上，如果固件只有两三 KB，用 24LC32 就够了；如果接近 8KB，建议直接用 24LC128，留出余量，也方便以后扩展配置参数。

这里有个特别容易踩的坑：EEPROM 的地址引脚 A0、A1、A2 一定不能悬空。很多开发板出厂时已经把这三个引脚接到 GND，对应的器件地址是 0x50，这没问题。但如果你自己画板子，或者从模块上拆了一颗 EEPROM 来用，地址引脚悬空的话，芯片内部读取到的地址状态可能不稳定，有时候能启动，有时候启动不了，非常玄学。我在调试时遇到过一次偶发性启动失败，最后就是 A2 引脚虚焊导致的。把 A0、A1、A2 全部接到 GND，然后确认 I2C 器件地址是 0x50，是 C0 模式最稳的接法。

还要注意 EEPROM 的写保护引脚 WP。若 WP 被拉高，EEPROM 只读不能写，你用 CyConsole 或编程器烧录时会提示写入失败，或者写进去之后读出来全是 0xFF。很多二手拆机模块上 WP 引脚被强制接到了 VCC，需要你把它拉低才能烧录。

3.2 SCL/SDA 上拉和跳线

FX2LP 的 I2C 控制器引脚就是芯片上的 SCL 和 SDA，在部分封装里这两个引脚和普通 IO 复用。按官方要求，这两根线都需要接上拉电阻到 3.3V，阻值一般取 2.2K 到 10K 之间。开发板上如果已经集成 EEPROM，通常已经处理好了；如果是自己飞线接模块，上拉电阻必不可少。否则 bootloader 读 EEPROM 时会因为边沿太差而读不到数据，启动就会回落到 USB 下载模式。

如果你用的是网上常见的 CY7C68013A 开发板，板上可能有一个小跳线或者焊盘来控制 EEPROM 是否接入 I2C 总线。插上 EEPROM 或者焊接 0 欧电阻之后，芯片才会走 C0 模式。我之前遇到一个板子，EEPROM 明明焊在上面，读出来也有数据，可就是启动不了，最后发现是板子背面一个 0 欧电阻没焊，SCL 信号根本没连到 EEPROM 的时钟脚。这种问题纯靠看原理图很难发现，最好用万用表量一下 SCL 和 SDA 到 EEPROM 对应引脚的连通性。

3.3 时钟与复位：容易被忽略的启动前提

C0 模式启动的前提是芯片本身工作正常，而芯片正常工作的前提是时钟和复位都对。CY7C68013A 通常需要一颗 24MHz 晶振，如果你买的模块用的是 12MHz 晶振，一般芯片内部有倍频机制，但很多简化设计仍然直接按 24MHz 来做。晶振不起振或者频率偏差太大的话，USB 枚举会失败，C0 模式启动也没戏，因为 bootloader 可能从一开始就卡住了。

复位引脚也要重视。有些开发板为了省事，直接把 RESET# 接到 VCC 上，靠内部上电复位。这种设计大多数时候能用，但在电源爬升缓慢或存在大电容的场景下，复位释放过早会导致 bootloader 还没准备好就开始读 I2C，进而启动失败。如果你发现板子冷启动时经常不识别，热复位或者重新插拔 USB 后又正常，先查一下复位时序，再查 EEPROM。

4. 操作步骤：从 USB 加载到 C0 自动启动

4.1 先用 USB 下载模式验证固件本身

在烧任何 EEPROM 之前，我强烈建议先走一遍 USB 下载模式，确认固件本身没毛病。具体做法是：先把 EEPROM 拆掉，或者擦除到空白，让芯片上电后枚举成 04B4:8613 的加载器设备。然后用 cycfx2prog 直接把编译出来的 hex 下载到 RAM 里运行，命令大概是这样：

cycfx2prog firmware.hex

如果固件在 USB 下载模式下能正常工作，说明代码逻辑、描述符、中断、端点这些基本都没问题。接下来再做 C0 模式就只剩下“把固件塞进 EEPROM 并让 bootloader 正确加载”这一件事，排查范围一下子缩小了很多。

这一步不要省。如果你跳过它，直接在 C0 模式下调试，出现问题时你会分不清是固件 bug、EEPROM 写入错误、还是 bootloader 加载逻辑问题。把一个变量先固定住，是嵌入式调试的基本素养。

4.2 生成并烧写 C0 镜像

确认固件没问题后，生成 C0 镜像：

hex2bix -i -f 0xC0 -o firmware.iic firmware.hex

然后用十六进制工具打开确认文件头是 C0。接下来有两种烧写方式。第一种是用通用编程器，比如 CH341A，直接把 firmware.iic 写到 24LC64 里。注意有些编程器软件需要你把 .iic 当作原始二进制文件写入，起始地址从 0x0000 开始，不要填偏移。第二种是用 FX2LP 自己来写：先把芯片保持在 USB 加载模式，然后用 CyConsole 里的 EEPROM 烧写功能，把 .iic 通过 I2C 控制器写进 EEPROM。这个过程不需要额外硬件，前提是你的板子上有一颗空 EEPROM 并且当前固件能够枚举。

如果你喜欢命令行，cycfx2prog 也能操作 EEPROM，但不同的板子 I2C 地址可能不同，需要先确认 EEPROM 器件地址是 0x50。很多从没烧过 EEPROM 的人会在这里卡住，因为 CyConsole 烧写时如果一直显示超时，往往就是 A0/A1/A2 地址和工具默认值不一致。

4.3 上电验证与确认

烧完之后，把 USB 线拔掉，等一两秒让板子完全掉电，然后再重新插上。不要用热复位代替掉电，因为有些情况下 EEPROM 里的固件已经跑起来了，热复位并不能模拟真实的冷启动过程。

观察设备管理器或者 Linux 下的 lsusb 输出。如果设备枚举出来的 VID/PID 已经变成固件里自定义的值，说明 C0 模式启动成功了。如果还是 04B4:8613，先别急着怀疑 EEPROM，按第 5 节的排查链路一步步查。

另外，如果你的固件里没有 USB 重枚举代码，即使 C0 加载成功了，主机看到的仍然可能是原来的加载器描述符。此时你需要确认固件是否真的在运行，比如看板子上的 LED 是否变化、串口有没有打印、有没有产生中断。

5. 启动失败的排查链路

5.1 现象一：设备始终以 04B4:8613 枚举

这是最常见的情况。上电后电脑显示 04B4:8613，说明 bootloader 没有走 C0 模式，直接落到了 USB 下载模式。按下面的顺序排查：

1. 用编程器把 EEPROM 的内容读出来，看地址 0x00 处是不是 0xC0。如果看到的是 0xFF，说明 EEPROM 没烧进去，或者烧的地址不对。
2. 确认 EEPROM 的 A0、A1、A2 地址引脚已经固定，不能悬空。
3. 用万用表量 SCL、SDA 到 EEPROM 的连通性，特别是中间有跳线或 0 欧电阻的设计。
4. 确认 SCL、SDA 上有上拉电阻，量一下对地电阻是否正常。
5. 查看复位引脚和晶振波形。如果晶振都不起振，后面的所有步骤都没有意义。

我自己的排查顺序是先读 EEPROM，再量连通性，最后看波形。因为读 EEPROM 最直接，如果数据都是 0xFF，说明写入环节就有问题，没必要去动示波器。

5.2 现象二：固件在跑但没有重新枚举

这种更隐蔽。设备看起来还是 04B4:8613，但你发现板子上有运行迹象，比如 LED 在闪、串口在输出，说明 C0 模式其实已经加载成功了，只是 USB 重枚举没有成功完成。问题基本出在固件代码里。

很多 FX2LP 工程在初始化 USB 时，会通过写端点控制寄存器来触发断开和重新枚举，让主机重新读取自定义描述符。如果初始化顺序有问题，或者 USB 中断没有正确开启，重枚举就不会发生。你需要检查固件里是否调用了重枚举相关函数，以及调用位置是否在 main 函数的前期初始化路径上。还有一个容易忽略的坑：如果固件在重枚举之前就进入了一个死循环，主机就不会看到新设备。这种情况需要你把重枚举尽量提前，或者加一个延时后强制重枚举。

5.3 现象三：烧录后设备无法识别或反复掉线

设备管理器里显示“无法识别的 USB 设备”，或者插上后反复断开重连，这通常是硬件不稳定或者固件跑飞导致的。优先检查 3.3V 和 1.8V 供电纹波，尤其不要在 USB 线上串联又细又长的线材，供电不足会让 USB 物理层工作不正常。

接着检查 D+ 和 D- 走线，以及 24MHz 晶振两脚的负载电容。FX2LP 对晶振匹配电容比较敏感，电容值不对可能会导致频率偏差过大，USB 信号质量变差，设备枚举时好时坏。最后再考虑固件问题，比如代码里在 C0 模式下反复访问了不存在的地址，触发了 8051 的异常复位。你可以把 EEPROM 擦掉，看回到 USB 下载模式后板子是否稳定，如果回到加载模式就稳定，那问题大概率出在固件运行阶段。

5.4 用于排查的观察点

如果手头有逻辑分析仪，抓一下启动瞬间的 I2C 波形是最直接的。上电后应该能看到主机发起对 EEPROM 地址 0x50 的读操作。如果完全没有 I2C 波形，说明 bootloader 压根没认为总线上有 EEPROM，问题在硬件连接或者复位时序。如果能看到波形，但数据读出来是 0xFF，说明 EEPROM 空或者地址不对。这些波形信息比任何猜测都可靠。

6. C0 模式的容量边界与向 C2 模式过渡

6.1 8KB 内部 RAM 的限制

C0 模式是把固件放到 CY7C68013A 内部 8KB RAM 里执行，这个限制是硬性的。很多项目刚开始确实只有几 KB，但功能越加越多，字符串、Printf 调试信息、缓冲数组一上来，8KB 很快就满了。

你在 C0 模式下做优化时，可以从这几个方向入手：减少不必要的库函数，特别是 printf 系列的格式化输出；把只读的常量表放到 EEPROM 里，运行时按需读取；避免定义大数组，尤其不要一次性申请 1KB 以上的缓冲区。FX2LP 的端点 FIFO 实际上是独立的存储区域，不需要占用 8051 的通用 RAM，可以把 USB 缓冲放到端点缓冲区里。

还有一个比较实用的技巧：在链接脚本里把代码段、只读数据段、变量段分别放在内部 RAM 的不同区域，方便你用 map 文件查看哪里占了最多空间。编译后多看一眼 map 文件，比盲目猜要快很多。

6.2 C2 模式和外部存储接口

如果你的固件确实超过了 8KB，那就得考虑 C2 模式了。C2 模式下，bootloader 同样通过 I2C EEPROM 读加载记录，但记录里的目标地址可以是外部存储空间，8051 从外部存储器取指和执行。这样程序空间可以扩展到更大的范围，适合功能更复杂的工程。

但 C2 模式不是免费的午餐。FX2LP 要访问外部 RAM 或 Flash，必须把地址总线和数据总线接出来，这会占用 PB、PD 等大量引脚，导致很多 IO 功能没法再用。而且外部存储器的时序必须和 8051 的运动周期匹配，芯片手册里有相关配置寄存器，调起来比 C0 模式麻烦得多。如果你的项目没有特别大的代码需求，我还是建议先用 C0 模式把功能压到 8KB 以内，毕竟稳定性和开发效率更重要。

6.3 怎么选更省事

从我实际接触的项目看，C0 模式占了 FX2LP 应用的绝大多数。这个芯片的价值在于 USB 传输，而不是跑复杂算法。你如果真的需要跑大固件，要么换带更大 Flash 和 RAM 的芯片，要么用 C2 模式加外部存储器，但复杂度会明显上升。

最后分享一个很实用的习惯：无论在 C0 还是 C2 模式下，都别把 EEPROM 里的模式字节和固件一起做成“不可恢复”的状态。我的做法是保留一颗空 EEPROM 作为恢复工具，或者在产品测试点留一个跳线，能临时把 EEPROM 的 WP 拉高或者把 SCL 断开，让板子回到 USB 加载模式，方便重新烧录。这个习惯救过我很多次，因为 C0 模式下如果固件里有个死循环，而你又没法改 EEPROM，那就只能拆芯片了。