通过control center上位机读取USB芯片CY7C68013A数据失败的原因?怎么解决？

答案对人有帮助，有参考价值 0

好的，这个问题很经典，在CY7C68013A（FX2LP）配合Cypress Control Center使用批量传输时经常遇到。错误码997 (ERROR_IO_PENDING) 是关键线索。

根本原因分析:

1. 
   

   异步I/O操作 (Overlapped I/O):

   
   
   
   
   • Windows USB驱动在使用ReadFile进行批量传输时，默认（或通常配置为）使用异步I/O模式（Overlapped I/O）。
   
   
   • 在这种模式下，ReadFile调用会立即返回，即使数据传输尚未完成。
   
   
   • 返回值为TRUE表示I/O立即成功完成；返回值为FALSE且GetLastError()返回ERROR_IO_PENDING (997) 表示I/O操作已经成功启动，但还在后台进行中，没有完成。这不是一个致命的错误码。
   
   
   
   


2. 
   

   Control Center的行为：

   
   
   
   
   • Control Center是一个比较简单的通用测试工具。当它发起一个ReadFile请求时：
     
     
     
     • 对于读取512字节：传输数据量较大，需要的时间相对较长（微妙级，但对CPU周期来说很长），所以调用ReadFile返回FALSE，错误997的概率很高。但是Control Center在收到997后，通常会等待（调用WaitForSingleObject或类似函数）直到这个较大的传输完成，然后再去获取结果，所以最终成功。
     
     
     • 对于读取2字节：传输数据量极小，完成得非常快。当Control Center调用ReadFile时，极有可能在函数调用结束之前传输就已经在后台完成了。此时：
       
       
       
       • 理想情况：ReadFile应返回TRUE，表示立即成功完成，并填充数据缓冲区。
       
       
       • 常见情况 (碰到997)：ReadFile调用虽然发出了，但驱动在函数返回前的瞬间没有100%完成传输报告给Windows（由于时间太短，内核调度间隙），于是返回FALSE并将错误码置为997，表示I/O已启动但未完成（其实可能已经完成了或者即将在几纳秒后完成）。
       
       
     
     
   
   
   • 问题的核心： Control Center在收到997错误码后，可能没有正确地等待并获取这个实际上非常快完成的传输结果。它可能直接将997报告为错误而终止，没有检查操作是否随后完成。
   
   
   
   


3. 
   

   为什么先读512再读2字节也失败？

   
   
   
   
   • 虽然读512字节后系统（驱动队列）可能处于一个“忙碌”状态，但这个问题主要还是由读2字节的传输特性（极小、超快完成）与Control Center处理异步I/O的逻辑不完善共同导致的。即使前面有操作，读2字节本身仍然足够快，容易陷入上述的时间窗口陷阱。Control Center在两种情况下处理这个“瞬间完成”的小传输都失败了。
   
   
   
   

解决方案：

解决思路核心是正确处理ERROR_IO_PENDING状态。

1. 
   

   使用Control Center的“Continuous”模式（首选最简方法）：

   
   
   
   
   • Control Center的“Endpoint”选项卡通常有一个“Continuous”复选框或下拉菜单。
   
   
   • 操作： 在BULK IN端口的设置里，勾选“Continuous”（持续/流模式）。
   
   
   • 原理： 此模式下，Control Center在后台启动一个循环读取操作。它会：
     
     
     
     • 发起第一个ReadFile请求（可能得到997）。
     
     
     • 正确等待该请求完成（通过事件或完成例程）。
     
     
     • 一旦完成，立即用得到的数据刷新UI（如Hex View）。
     
     
     • 然后立即发起下一个ReadFile请求，形成持续读取流。
     
     
   
   
   • 结果： 无论读取1字节、2字节还是512字节，Control Center都能正确处理异步I/O的结果，包括处理快如闪电的小传输。你会看到数据源源不断地（或者在你手动点击“Stop”之前）显示出来。将期望的字节数设置成2，然后以Continuous模式读取，它应该是能正常显示2字节数据的。
   
   
   • 这是解决Control Center自身读取小包问题的最直接、最有效的方法。
   
   
   
   


2. 
   

   增大Control Center超时（可能有效，非根本解决）：

   
   
   
   
   • 在Control Center的设置里（通常在Setup -> Options或类似地方），找找关于超时(Timeout)的设置。
   
   
   • 操作： 尝试将USB操作的超时时间（特别是Read超时）增大一点（例如从默认的1000ms改到2000ms、5000ms甚至10000ms）。尝试设置无限等待（如果选项存在）。
   
   
   • 原理： 这给了Control Center更多的“耐心”去等待那个即使997状态但实际上早已完成的传输。理论上，即使它错误报告了997，多等一会儿再去检查结果也能成功。
   
   
   • 局限性： 这个修改主要是为解决因等待时间不足导致误判为失败的大传输设计的。对于快如闪电的小传输（本质是状态处理和刷新时机问题），超时增大不一定总能解决，不如Continuous模式可靠。但值得一试。
   
   
   
   


3. 
   

   使用 EzUsbCmd 命令行工具（更底层控制）：

   
   
   
   
   • Cypress USB Suite通常包含一个命令行工具 EzUsbCmd.exe (可能在 Bin 目录下)。
   
   
   • 操作： 打开命令提示符（cmd），导航到 EzUsbCmd.exe 所在目录。
   
   
   • 读取语法示例： EzUsbCmd.exe -rd -ep -len -tout
     
     
     
     • ：目标设备的VID/PID（16进制，如-rd 0x04b4 0x8613）。
     
     
     • ：批量IN端点号（如 0x86）。
     
     
     • ：要读取的字节数（如 2）。
     
     
     • ：读取超时（毫秒，设为0可能表示无限等待，或设置较大值如5000）。
     
     
   
   
   • 优点： EzUsbCmd 在内部逻辑上更严谨地处理了异步I/O的等待。对于小批量读取通常很可靠。你可以写一个批处理文件让它多次读取2字节。
   
   
   • 缺点： 需要命令行操作，不如GUI直观。
   
   
   
   


4. 
   

   编写自定义上位机（开发者解决方案）：

   
   
   
   
   • 如果是最终产品集成，建议使用Cypress提供的CyAPI库（C++）或其他USB库（如libusb）编写自己的应用程序。
   
   
   • 核心逻辑：
     
     
     
     • 使用异步（Overlapped）方式调用 ReadFile。
     
     
     • 检查返回值：
       
       
       
       • TRUE：传输立即完成，数据在缓冲区。
       
       
       • FALSE & GetLastError() == ERROR_IO_PENDING：传输已启动，尚未完成。此时必须调用 WaitForSingleObject 或 GetOverlappedResult 等待操作完成（或超时）。
       
       
     
     
     • 在等待函数返回成功后（如 WAIT_OBJECT_0），调用 GetOverlappedResult 获取实际传输字节数和最终操作状态（即使返回TRUE也需要调用它来确认实际传输量）。
     
     
   
   
   • 优点： 完全掌控异步操作流程，对小数据传输处理最可靠。
   
   
   • 缺点： 需要一定的开发工作量。
   
   
   
   

总结与建议：

1. 首选方案： 在Control Center的Endpoint设置中启用“Continuous”模式。这是解决此问题的“官方”快捷方式，通常能立即奏效。


2. 尝试方案： 如果禁用Continuous或不适合，增大Control Center的读取超时时间，并尝试再次读取2字节。


3. 临时测试方案： 使用 EzUsbCmd.exe 命令行工具进行小批量读取测试。


4. 根本解决方案 (开发时)： 编写自定义上位机应用，正确处理 ERROR_IO_PENDING 状态，确保在调用ReadFile并收到997后，正确地等待操作完成并使用GetOverlappedResult获取结果。不要将997视为最终错误。

请优先尝试“Continuous”模式，这应该是你最快、最直接的解决途径。 记住，错误997的本质是“操作还没报告完成”，而不是“操作失败”，关键在于正确处理这个中间状态。