CyU3PDmaChannelGetStatus和GPIF可能存在互斥问题？

这是一个有点长的描述，所以请容忍我。
-
我们有GPIFSET到100.8兆赫。是的，比额定的速度稍快，但是使用19.2MHz晶体时的最高速度似乎是100.8 MHz（403.2／4）或89.6兆赫。我们曾希望GPIFET会因为性能原因而超频0.8%。这个问题在室温下至少在几个板上是可重复的，所以它似乎与工艺限制无关。
-
我们有一个GPIFI描述，可以用一个外部的“就绪”信号在块中传输。块等待，直到“准备”被断言，然后进行。这一直持续到整个传输完成为止。
-
由于存在此就绪信号，主机必须检查FX3，以查看当执行“写入”操作（主机到FX3到GPIF）时传输是否完成。关键是GPIFS需要一些时间来刷新DMAbuffer来真正完成传输，即使主机已经通过USB批量传输发送了所有内容。因此，主机使用供应商命令来检查FX3来检查状态。同时查询DMACMOMPLANCE状态和GPIF状态。
-
我们发现一些有趣的数据损坏问题时，执行传输，利用就绪信号，以减缓传输。值得注意的是，当这些腐败问题存在时，它们就像DRMDATAPOtiN被精确地减少了8（在我们的32位GPIFinterface上执行时，32字节）。在下一个“块”（记住，我们逐个地检查就绪信号），DRI数据指针返回到它应该的位置。因此，当发生损坏时，我们只得到坏的数据，直到块的末尾。然后一切恢复。
-
由于我们正等待GPIFTO完成，我们可以在主机上放置一个短延迟（25MS），而忽略状态检查。当我们这样做时，不会发生数据损坏。
-
事实上，即使我们在批量传输之后立即执行状态检查（USB供应商请求），但是DooToCaldMaChannGETStand，不会发生任何损坏。
-
如果设置GPIFTO 89.6 MHz，则不会发生损坏。
-
如果我们使用就绪信号传输，则不会发生损坏。据推测，这是因为在我们有机会调用DMACHANNEL GETSTATE之前，传输完成。
-
注意，所有的DMACHANNEL GETSATH都返回CYU-U3PY-PROCENIN所有的情况。我们发现有趣的是，APIGIDE要求出现错误错误的可能性，因为这种问题通常是数据共享问题的结果。没有源代码，就不可能检查，但是我们怀疑DMACHANEL GETStand可能会损坏数据指针中间传输。
-
所以我可以说我们在这里有一些事情：
-
1。设置GPIFTO 89.6 MHz，并进行性能惩罚。
-
2。DooToDMACHANNEL GETSATH来确定传输完成状态。这会破坏我们的数据。相反，我们只使用CYU3PGPIFGETSMSTATE，并根据该信息确定完成。这很好，没有数据损坏。



     以下为原文
  This is a bit long to describe so please bear with me.
    -
    We have GPIF setup to 100.8 MHz.  Yes, slightly faster than it is rated to go, but the top speed when using 19.2 MHz crystal seems to be either 100.8 MHz (403.2 / 4) or 89.6 MHz.  We had hoped the GPIF would run 0.8% overclocked for performance reasons.  This problem is reproducible on at least a couple boards at room temperature, so it doesn't seem to be related to the process limitation.s
    -
    We have a GPIF description that can transfer in blocks with an external "ready" signal.  The block waits until "ready" is asserted, then proceeds.  This continues until the entire transfer is complete.
    -
    Due to the presence of this ready signal, the host must check the FX3 to see if the transfer is complete when performing a "write" operation (host to FX3 to GPIF).  The point is that the GPIF needs some time to flush the DMA buffer to truly complete the transfer, even though the host has sent everything via USB bulk transfers.  So the host pings the FX3 using a vendor command to check the status.  Both DMA completion status and GPIF state are queried.
    -
    We found some interesting data corruption issues when performing transfers that utilize the ready signal to slow down the transfer.  It's notable that when these corruption issues exist, they are as if the DR_DATA pointer has been decreased by exactly 8 (32 bytes when performing on our 32-bit GPIF interface).  At the next "block" (remember, we check the ready signal on a block-by-block basis), the DR_DATA pointer is back to where it's supposed to be.  So when the corruption occurs, we are only getting bad data until the end of the block.  Then everything resumes.
    -
    Since we're just waiting for GPIF to complete, we can put a short delay (25ms) at the host and ignore the status check.  When we do this, no data corruption occurs.
    -
    In fact, even if we perform the status check (USB vendor request) immediately after the bulk transfer, but DO NOT CALL DmaChannelGetStatus, no corruption occurs.
    -
    If we set the GPIF to 89.6 MHz, no corruption occurs.
    -
    If we DO NOT slow the transfer using the ready signal, no corruption occurs.  Presumably, this is because the transfer completes before we have the opportunity to call DmaChannelGetStatus.
    -
    Note that DmaChannelGetStatus returns CY_U3P_SUCCESS in all cases.  We found it interesting that the API guide calls for the possibility of a ERROR_MUTEX_FAILURE because this sort of issue is often the result of a data sharing issue.  Without the sources, it's impossible to check, but we suspect there may be an issue with DmaChannelGetStatus that may be corrupting data pointers mid-transfer.
    -
    So I should say we have TWO resolutions here:
    -
    1. Set the GPIF to 89.6 MHz and take the performance penalty.
    -
    2. DO NOT use DmaChannelGetStatus to determine the transfer completion status.  This corrupts our data.  We instead use only CyU3PGpifGetSMState and determine completion from that information.  This works just fine and no data corruption is seen.