Harmony USB HOST CDC锁定，TOKBUSY卡在PIC32上

我的设置的一些细节：PIC32 MX2170F256D被用于USB主机模式，在2.03b的谐波（虽然以前同样在2.01b上看到过），使用动态USB FS主机驱动来自OrthyUSB始终是供电的，而VBuSyon引脚用于其他目的。时间的长短，能够对CDC设备进行良好的收发。然而，在从CDC设备到PIC32的持续一个单向高流量负载之后，PIC32上的USB外围设备锁定，并且拒绝通过USB发送或接收任何更多的业务。PIC32行为的其余部分保持正常。一旦在这种模式下，PIC32仍然可以检测是否删除/重新插入USB设备，但无法与任何设备进行通信。（这意味着它不能正确地识别我插入的任何设备，即使它检测到我插入它……）我比较了一组和谐的数据结构和工作和非工作之间的外围寄存器，我注意到的唯一一件事就是U1CON的TokCube位被困在1点。R锁定（即使我删除和重新插入USB设备，仍然会被卡住）。我搜索了论坛，我发现TokCube卡的唯一引用是BDT管理不当或乒乓缓存机制错误引起的问题。在我的系统中，和谐正在管理这些，所以我怀疑我正在追踪和谐代码中的bug……有人知道会导致Tok忙碌标志被设置和永远不清除的任何其他原因吗？作为一个远景，有没有其他人发现这个错误在和谐USB主机代码？最后，是否有一个特定的寄存器，如果我即时检测到它，我可能会尝试在USB上颠簸来解决这个问题。显然，我宁愿找到并修复根本原因，但我们的应用程序的细节可以处理一个小嗝每隔几分钟，如果这是唯一的办法绕过它。



      以下为原文

    Some specifics of my setup:

• PIC32MX270F256D being used in USB host mode only
• HARMony 2.03b (although this same bug was previously seen on 2.01b as well)
• Using dynamic USB FS HOST drivers from Harmony
• USB is always powered, and the VBUS_ON pin is used for other purposes
  

The system works fine the vast majority of the time, and is able to transmit and receive to the CDC device just fine.  However, after a few minutes of sustained one-directional high-traffic workload from the CDC device to the PIC32, the USB peripheral on the PIC32 locks up and refuses to send or receive any more traffic over USB.  The rest of the PIC32 behavior remains normal.

Once in this mode, the PIC32 can still detect if I remove/reinsert a USB device, but is unable to communicate with any devices. (Which means it can't properly identify any device I plug in even though it detects me inserting it...)  I compared a bunch of Harmony data structures and peripheral registers between working and non-working, and the only concerning thing I noticed is that the TOKBUSY bit of U1CON is stuck at 1 after the lockup (and remains stuck even if I remove and reinsert the USB device).  I searched the forums and the only references I found to TOKBUSY being stuck were issues caused by BDT mismanagement or mistakes with the ping-pong buffer mechanism.  In my system Harmony is managing those, so I am suspicious that I'm chasing a bug in Harmony code...

Is anyone aware of any other causes that would lead to the TOKBUSY flag being set and never cleared?

As a long shot, has anyone else found this bug in the Harmony USB host code?

And, finally, is there a particular register I might try bumping on the USB to workaround this issue if I detect it on the fly?  Obviously, I would rather find and fix the root cause, but the particulars of our application can deal with a small hiccup every few minutes if that's the only way to get around it.