USB论坛

李辉

8年用户 1422经验值

私信关注

[问答]

cy7c68013a slave fifo写数据出现异常的原因？怎么解决？

Hi all,
我使用68013A和MCU采用Slave Fifo 异步方式进行通讯，EP2为AUTOOUT，EP6为AUTOIN，16位。现在有一个奇怪的现象出现，当通过mcu发送0x00 00 ff ff 00 00 00 00时, PC端接收到的数据总是00 00 7f 1f 00 00 00 00, 而当将最后一位改为0xff后，PC接收到的数据就正常了。
发现有一个规律，当开始为00 00, 结尾为00 00 00 00时，数据包中的0xff数据就有可能会有变化。

这个问题怎么解啊？请各位帮忙！谢谢！

回帖（1）

贾熹

2025-6-13 17:08:39

我理解你目前遇到的CY7C68013A Slave FIFO数据传输异常问题确实令人困惑。根据你的描述，特别是00 00 FF FF 00 00 00 00变成00 00 7F 1F 00 00 00 00，并且只有当末尾字节为0xFF时才能传输成功，以下是可能的原因和解决办法分析：

问题根本原因分析

Slave FIFO的自动打包机制（Auto Packetization）问题 - 这是最核心、最可能的原因：
- CY7C68013A的AUTOIN/AUTOOUT端点使用自动打包功能。
- 这个机制的工作原理是：当固件（FX2LP）检测到以下任一条件时，会自动向USB总线提交当前FIFO中的数据作为一个完整的数据包：
  - 数据量达到设定的包大小上限(wMaxPacketSize)。
  - 收到固件发出的INPKTEND命令（仅对IN端点有效）。
  - 检测到FLAGx标志指示FIFO为空（或低于某个阈值）（这主要与IN端点的手动/自动模式选择有关）。
- 问题核心： 在你发送00 00 FF FF 00 00 00 00时，68013可能误判了数据包的结束点，导致将非完整数据提前打包发送了。
- 错误产生的推测过程：
  - MCU开始向EP6 FIFO写数据：00, 00, FF, FF, 00, 00, 00, 00。
  - 68013固件监测FIFO状态（通常通过FLAG引脚或内部状态寄存器）。
  - 当写入FF, FF后，FIFO中有4字节数据（2个16位字）。
  - 如果接下来的两个00被写入FIFO后（此时共有00 00 FF FF 00 00，6字节数据），68013可能错误地认为此时已经满足某个发送条件（例如认为FIFO内有足够数据、或FLAG信号短暂触发空标志），在未收到INPKTEND信号的情况下，错误地将这6字节数据打包并发送出去。但USB包大小通常是64字节（512字节）或其倍数，而你的有效数据包只有8字节，所以可能还有其他标志触发了打包逻辑。
  - 当最后一个字节被改为FF后，数据变为00 00 FF FF 00 00 00 FF。这种情况下可能FLAG信号未误触发或68013正确等到INPKTEND才发送数据，因此整个8字节作为完整包被正确传输。
- 7F 1F的含义：
  - 7F（二进制0111 1111）和1F（二进制0001 1111）很可能是误打包那一刻FIFO状态寄存器（如EP6FIFOFLGS）或其他内部状态的值被误写入数据流。
  - 当68013错误地认为需要发送包时，可能临时将一些标志寄存器（特别是EPxFIFOFLGS）的值当成了FIFO中的数据。7F和1F非常符合状态寄存器位的特征。

FLAGC/FLAGD标志映射冲突（可能性较高）：
- FX2LP的FLAGx（A、B、C、D）可用于指示FIFO状态（如空、满、可编程标志）。
- 这些FLAGx引脚通过内部寄存器映射到FX2LP的地址/数据总线的某些位（如FIFOADR[1:0]）。
- 错误产生的可能原因：
  - 当MCU连续写入00值到FIFO时（尤其是在数据结尾处），可能使内部FIFOADR状态（或其映射）发生改变，暂时将标志寄存器映射到了数据位。
  - 关键验证点： 检查你的固件代码中对FLAGx的设置（PINFLAGSAB，PINFLAGSCD寄存器），确保没有将标志映射到可能冲突的地址位（尤其是在发送大量零的情况下）。如果FLAGx配置不当，可能会导致标志信号被当成数据写入。

时序或信号完整性问题（可能性较低，但需检查）：
- 在Slave FIFO异步模式下，时序要求严格（如SLWR，PKTEND，IFCLK）。
- 数据线出现FF（所有位跳变）或00（所有位为低电平）时，总线易受干扰，导致数据传输异常。
- 解决方法建议：
  - 确保所有相关信号线（包括时钟IFCLK）符合时序规范，特别是建立/保持时间。
  - 检查PCB布线，避免数据线过长或有串扰。
  - 在数据线（FD[15:0]）上加下拉电阻（如10KΩ），可提升信号稳定性。

针对性解决方法建议

1. 明确手动触发包结束（最重要！）

在MCU端，每次写入一个完整数据包后，主动发送一个PKTEND信号（将PKTEND引脚置低一个周期）。

// MCU伪代码示例

for (int i = 0; i < PACKET_SIZE_IN_WORDS; i++) {

  WriteWordToFIFO(data[i]);  // 写入数据到FIFO

}

AssertPKTEND();                // 关键：显式触发包结束

DeassertPKTEND();

固件层面确保：
- 对IN端点（EP6），在固件初始化时，禁用基于“FIFO空”标志的自动提交功能。
- 在SlaveFIFO.c或类似文件中设置：
```
SYNCDELAY; EP6FIFOCFG = 0x00; // 或 0x02（注意设置说明）

// 通常设置为0x00（AUTOOUT+自动提交禁用），确保手动PKTEND触发
```

2. 严格检查`FLAGx`标志配置

在固件中查看PINFLAGSAB、PINFLAGSCD寄存器的设置。推荐配置：

SYNCDELAY; PINFLAGSAB = 0x8E;   // 常用配置：FLAGA(EP2 Empty), FLAGB(EP6 Full)

SYNCDELAY; PINFLAGSCD = 0x00;    // FLAGC/D不用于标志输出（避免冲突）

确保FLAGx没有映射到FIFOADR[1:0]（查看寄存器设置），以避免数据冲突。

3. 优化固件端点配置

检查EP6（AUTO IN）的配置：

SYNCDELAY; EP6CFG = 0xA0;      // VALID, IN, TYPE=BULK, SIZE=512(如果16bit，实际有效包大小是1024字节？)

SYNCDELAY; EP6FIFOCFG = 0x10;   // AUTOIN=1, ZERO-LENGTH IN=0, WORDWIDE=1 (16-bit)

关注EP6FIFOCFG：确保AUTOIN使能，但INPKTEND触发方式正确。

4. 用逻辑分析仪精准定位故障点

监控信号： FD[15:0], SLWR, FIFOADR[1:0], PKTEND, IFCLK。

重点观察：
- 当发送问题数据时，PKTEND是否在正确时间点被MCU触发？
- FIFOADR在数据传输过程中是否有意外变化？
- 在数据出错位置附近是否有干扰（如FF跳变时出现振铃）。

5. 测试固件强制提交逻辑

作为诊断测试，在固件中强制在每个有效包后插入INPKTEND（即使未满）：

// 在TD_Poll()或类似地方

if (/* 包就绪条件 */) {

  SYNCDELAY; EP6BCL = 0x00; // 触发IN包发送（自动提交模式）

  // 或使用 INPKTEND 手动提交

}

这能验证是否自动逻辑触发过早。

总结

从现象（FF FF变7F 1F、00结尾触发异常、FF结尾可正常）来看，极可能是FX2LP误判包结束点，导致状态标志被误写入数据流。最有效的解决手段是在MCU端每个数据包后手动触发PKTEND，并确认固件中Slave FIFO配置为等待此信号。只要包结束信号被精确控制，问题通常即可解决。

问题根本原因分析

Slave FIFO的自动打包机制（Auto Packetization）问题 - 这是最核心、最可能的原因：
- CY7C68013A的AUTOIN/AUTOOUT端点使用自动打包功能。
- 这个机制的工作原理是：当固件（FX2LP）检测到以下任一条件时，会自动向USB总线提交当前FIFO中的数据作为一个完整的数据包：
  - 数据量达到设定的包大小上限(wMaxPacketSize)。
  - 收到固件发出的INPKTEND命令（仅对IN端点有效）。
  - 检测到FLAGx标志指示FIFO为空（或低于某个阈值）（这主要与IN端点的手动/自动模式选择有关）。
- 问题核心： 在你发送00 00 FF FF 00 00 00 00时，68013可能误判了数据包的结束点，导致将非完整数据提前打包发送了。
- 错误产生的推测过程：
  - MCU开始向EP6 FIFO写数据：00, 00, FF, FF, 00, 00, 00, 00。
  - 68013固件监测FIFO状态（通常通过FLAG引脚或内部状态寄存器）。
  - 当写入FF, FF后，FIFO中有4字节数据（2个16位字）。
  - 如果接下来的两个00被写入FIFO后（此时共有00 00 FF FF 00 00，6字节数据），68013可能错误地认为此时已经满足某个发送条件（例如认为FIFO内有足够数据、或FLAG信号短暂触发空标志），在未收到INPKTEND信号的情况下，错误地将这6字节数据打包并发送出去。但USB包大小通常是64字节（512字节）或其倍数，而你的有效数据包只有8字节，所以可能还有其他标志触发了打包逻辑。
  - 当最后一个字节被改为FF后，数据变为00 00 FF FF 00 00 00 FF。这种情况下可能FLAG信号未误触发或68013正确等到INPKTEND才发送数据，因此整个8字节作为完整包被正确传输。
- 7F 1F的含义：
  - 7F（二进制0111 1111）和1F（二进制0001 1111）很可能是误打包那一刻FIFO状态寄存器（如EP6FIFOFLGS）或其他内部状态的值被误写入数据流。
  - 当68013错误地认为需要发送包时，可能临时将一些标志寄存器（特别是EPxFIFOFLGS）的值当成了FIFO中的数据。7F和1F非常符合状态寄存器位的特征。

FLAGC/FLAGD标志映射冲突（可能性较高）：
- FX2LP的FLAGx（A、B、C、D）可用于指示FIFO状态（如空、满、可编程标志）。
- 这些FLAGx引脚通过内部寄存器映射到FX2LP的地址/数据总线的某些位（如FIFOADR[1:0]）。
- 错误产生的可能原因：
  - 当MCU连续写入00值到FIFO时（尤其是在数据结尾处），可能使内部FIFOADR状态（或其映射）发生改变，暂时将标志寄存器映射到了数据位。
  - 关键验证点： 检查你的固件代码中对FLAGx的设置（PINFLAGSAB，PINFLAGSCD寄存器），确保没有将标志映射到可能冲突的地址位（尤其是在发送大量零的情况下）。如果FLAGx配置不当，可能会导致标志信号被当成数据写入。

时序或信号完整性问题（可能性较低，但需检查）：
- 在Slave FIFO异步模式下，时序要求严格（如SLWR，PKTEND，IFCLK）。
- 数据线出现FF（所有位跳变）或00（所有位为低电平）时，总线易受干扰，导致数据传输异常。
- 解决方法建议：
  - 确保所有相关信号线（包括时钟IFCLK）符合时序规范，特别是建立/保持时间。
  - 检查PCB布线，避免数据线过长或有串扰。
  - 在数据线（FD[15:0]）上加下拉电阻（如10KΩ），可提升信号稳定性。

针对性解决方法建议

1. 明确手动触发包结束（最重要！）

在MCU端，每次写入一个完整数据包后，主动发送一个PKTEND信号（将PKTEND引脚置低一个周期）。

// MCU伪代码示例

for (int i = 0; i < PACKET_SIZE_IN_WORDS; i++) {

  WriteWordToFIFO(data[i]);  // 写入数据到FIFO

}

AssertPKTEND();                // 关键：显式触发包结束

DeassertPKTEND();

固件层面确保：
- 对IN端点（EP6），在固件初始化时，禁用基于“FIFO空”标志的自动提交功能。
- 在SlaveFIFO.c或类似文件中设置：
```
SYNCDELAY; EP6FIFOCFG = 0x00; // 或 0x02（注意设置说明）

// 通常设置为0x00（AUTOOUT+自动提交禁用），确保手动PKTEND触发
```

2. 严格检查`FLAGx`标志配置

在固件中查看PINFLAGSAB、PINFLAGSCD寄存器的设置。推荐配置：

SYNCDELAY; PINFLAGSAB = 0x8E;   // 常用配置：FLAGA(EP2 Empty), FLAGB(EP6 Full)

SYNCDELAY; PINFLAGSCD = 0x00;    // FLAGC/D不用于标志输出（避免冲突）

确保FLAGx没有映射到FIFOADR[1:0]（查看寄存器设置），以避免数据冲突。

3. 优化固件端点配置

检查EP6（AUTO IN）的配置：

SYNCDELAY; EP6CFG = 0xA0;      // VALID, IN, TYPE=BULK, SIZE=512(如果16bit，实际有效包大小是1024字节？)

SYNCDELAY; EP6FIFOCFG = 0x10;   // AUTOIN=1, ZERO-LENGTH IN=0, WORDWIDE=1 (16-bit)

关注EP6FIFOCFG：确保AUTOIN使能，但INPKTEND触发方式正确。

4. 用逻辑分析仪精准定位故障点

监控信号： FD[15:0], SLWR, FIFOADR[1:0], PKTEND, IFCLK。

重点观察：
- 当发送问题数据时，PKTEND是否在正确时间点被MCU触发？
- FIFOADR在数据传输过程中是否有意外变化？
- 在数据出错位置附近是否有干扰（如FF跳变时出现振铃）。

5. 测试固件强制提交逻辑

作为诊断测试，在固件中强制在每个有效包后插入INPKTEND（即使未满）：

// 在TD_Poll()或类似地方

if (/* 包就绪条件 */) {

  SYNCDELAY; EP6BCL = 0x00; // 触发IN包发送（自动提交模式）

  // 或使用 INPKTEND 手动提交

}

这能验证是否自动逻辑触发过早。

总结

更多回帖

李辉

cy7c68013a slave fifo写数据出现异常的原因？怎么解决？

回帖（1）

贾熹

问题根本原因分析

针对性解决方法建议

1. 明确手动触发包结束（最重要！）

2. 严格检查`FLAGx`标志配置

3. 优化固件端点配置

4. 用逻辑分析仪精准定位故障点

5. 测试固件强制提交逻辑

推荐解决步骤（优先级排序）

总结

问题根本原因分析

针对性解决方法建议

1. 明确手动触发包结束（最重要！）

2. 严格检查`FLAGx`标志配置

3. 优化固件端点配置

4. 用逻辑分析仪精准定位故障点

5. 测试固件强制提交逻辑

推荐解决步骤（优先级排序）

总结

相关问答

cy7c68013a slave fifo写数据出现异常的原因有哪些？如何解决？

cy7c68013a固件已经配置成异步slave模式，是否有MCU用IO口控制cy7c68013a通过数据总线来实现与PC的USB口通信？

CY7C68013A停止随机填充FIFO缓冲区

MCU是否可以使用普通IO口和数据总线控制cy7c68013a，用异步slavefifo模式增加一个与PC通信的USB口?

CY7C68013A不能和labview连续通信

请问CY7C68013A是否支持1MHz I2C频率？

如何在CY7C68013A中扩展FIFO的数量和大小？

怎么在Cy7C68013A上进行调试

cy7c68013a slave fifo写数据出现异常

Windows 10的CY7C68013A的驱动程序是否支持？

20万+工程师都在用，免费PCB检查工具

李辉

cy7c68013a slave fifo写数据出现异常的原因？怎么解决？

回帖（1）

贾熹

问题根本原因分析

针对性解决方法建议

1. 明确手动触发包结束（最重要！）

2. 严格检查FLAGx标志配置

3. 优化固件端点配置

4. 用逻辑分析仪精准定位故障点

5. 测试固件强制提交逻辑

推荐解决步骤（优先级排序）

总结

问题根本原因分析

针对性解决方法建议

1. 明确手动触发包结束（最重要！）

2. 严格检查FLAGx标志配置

3. 优化固件端点配置

4. 用逻辑分析仪精准定位故障点

5. 测试固件强制提交逻辑

推荐解决步骤（优先级排序）

总结

相关问答

cy7c68013a slave fifo写数据出现异常的原因有哪些？如何解决？

cy7c68013a固件已经配置成异步slave模式，是否有MCU用IO口控制cy7c68013a通过数据总线来实现与PC的USB口通信？

CY7C68013A停止随机填充FIFO缓冲区

MCU是否可以使用普通IO口和数据总线控制cy7c68013a，用异步slavefifo模式增加一个与PC通信的USB口?

CY7C68013A不能和labview连续通信

请问CY7C68013A是否支持1MHz I2C频率？

如何在CY7C68013A中扩展FIFO的数量和大小？

怎么在Cy7C68013A上进行调试

cy7c68013a slave fifo写数据出现异常

Windows 10的CY7C68013A的驱动程序是否支持？

20万+工程师都在用，免费PCB检查工具

2. 严格检查`FLAGx`标志配置

2. 严格检查`FLAGx`标志配置