【问题标题】:WinUsb: Write to OUT pipe causes data corruption in the IN pipeWinUsb:写入 OUT 管道会导致 IN 管道中的数据损坏
【发布时间】:2017-09-22 18:51:51
【问题描述】:

这是我第一个使用 WinUsb 驱动程序和库的项目。

我的主机运行 WINDOWS 10,安装了所有更新。
我的高速设备运行三个数据端点:

  • OUT 命令端点:主机使用它发送命令
  • IN 回复端点:主机接收对每个命令的回复
  • IN Stream 端点:设备发送流数据,1600 字节,周期为 10 毫秒。

在 Host 应用程序中,有两个相关线程:

  • 命令线程向命令管道发送命令并从回复管道接收回复
  • Stream 线程从 Stream pipe 收集数据

非等待函数用于所有管道。

如果另一个线程被挂起,每个线程都能完美运行。
但是,如果两个线程同时工作,则流数据会在任意点出现损坏。

更多分析揭示了以下事实:

  • 损坏显示为错误字节的连续序列。这 错误序列的长度大致对应于 命令和回复。
  • 错误的序列从与数据包边界无关的任意点开始。
  • 错误的字节可能不同;有时,它们都是零, 有时它们看起来像垃圾。
  • 时间分析表明,一旦命令执行,就会发生损坏 发送到命令管道。

如果我实现线程之间的同步,效果消失,这样读/写操作在时间上是分开的。但是,这是不可接受的解决方案,我希望两个线程异步工作。
有人遇到过这样的后果吗?

【问题讨论】:

  • 没有太多理由怀疑这个库,尤其是考虑到它被锤击的频率和它的作用很小。更有可能的是,这在设备固件中出错了。做有效的事。
  • 设备固件是我的第一个猜测,特别是因为它也是我项目的一部分。因此,我在传输前后实施了流缓冲区完整性检查。没有发现问题。
  • 如果没有库或固件 - 那么,只剩下硬件了吗?

标签: c# thread-safety winusb


【解决方案1】:

回答我自己的问题...

Hans 的评论是正确的,问题出在固件上。

设备固件开发人员可能会对更多细节感兴趣,尤其是如果他们像我一样使用 Atmel Cortex M7 系列。

在本系列中,USB 控制器包括用于端点缓冲的双端口 RAM。 DPRAM 仅由硬件分配和管理。固件通过设置端点控制寄存器中的 ALLOC 位来初始化分配。用户手册要求固件应按升序设置 ALLOC 位。有一次在项目历史中,我更改了端点描述符中的端点地址,但没有意识到这种更改违反了 DPRAM 分配的升序。结果,端点缓冲区出现重叠,导致问题中描述的数据干扰。

修复错误后,一切正常。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2011-02-12
    • 1970-01-01
    • 1970-01-01
    • 2011-07-13
    • 2020-01-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多