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.

Jake,

I wouldn't recommend over-clocking GPIF II. Are you seeing the issue if you use 100MHz?

Regards,

Anand

:)  We figured that would be the official response.

-

Unfortunately, we're not aware of any way to use the 19.2MHz crystal and set the GPIF to exactly 100 MHz.  If you have suggestions, I'd be interested.

-

We would like to try to drive the GPIF with an external 100 MHz clock, but since we've got a workaround for the DmaChannelGetStatus bug, we're not terribly motivated to do that.

Please create a tech support case (MyAccount -> MyCases), it would better if one of our engineers takes a deeper look to see if we can provide a cleaner workaround or at least analyze why the API is causing the corruption.

Regards,

Anand 

Sounds good in theory.  Unfortunately, with Cypress tech support, we've found the interaction to be extremely slow and frustrating.

-

Create support case... Wait two days... Question is asked, so we answer it... Wait two days... Further clarification is required and they want us to perform a test case -- so we spend an hour or two bringing up the project to where it was a week prior, run the test case, report back... Wait four days... Another question... Wait three days... They need another test case which can't easily be worked into the way the firmware is structured, etc.

-

Bottom line is it's a grueling process and we've just learned to work around things rather than try to get to the bottom of them.  I'll say this is a better setup than was in place when the FX2 was king, but it's effectively the same.  By the time tech support is able to address anything but the most basic "see the documentation" sort of questions, we've had to move the project along.

Hi Jake,

We've a excellent tech support team. Using the new case that was created for this I tried looking up your case history to understand what caused this opinion. I was not able to get the necessary details.

Please provide case number details, I want to get to the bottom of this.

Regards,

Anand

Anand, an example is case #1460802838.

-

We are noticing that if we setup the IOMatrix for 32-bit GPIF, we can use 16-bit GPIF or 32-bit GPIF without issue.  Furthermore, we can switch from 16-bit GPIF to 32-bit GPIF without issue.

-

However, if we then try to switch back from 32-bit GPIF to 16-bit GPIF, data transfers are not correct.  We were told that 16-bit to 32-bit GPIF is apparently an allowed configuration but that we would need to reconfigure the IOMatrix to go 32-bit GPIF to 16-bit GPIF.  This is not acceptable in our setup as it would require the USB to be de-configured and therefore an enumeration cycle and other undesirable effects.

-

In the end, we have a workaround (as with do with the 100.8 MHz DmaChannelGetStatus bug), so we aren't interested in pursuing further.  But what I expected to be a 24-72 hr response when the right people are involved has take two weeks.  And the vague answers by tech support don't give me much confidence that the true root cause of these things has been found.  It seems that the 32-/16-bit GPIF issue could well have a software fix (SDK update), but that's not clear at all from the feeling of confidence I get from this first-layer tech support.

Jake,

I've pinged the corresponding teams. Tech support is something we take very seriously. We'll get to the bottom of this and make sure you'll get better support.

Regards,

Anand

Anand--

Your ping helped.  Had a phone call this afternoon and (to our surprise) actually got to the bottom of a fairly difficult issue to dig into.  The end result is that for 32-bit, 100 MHz GPIF, the GpifSocketConfigure() API should be called with a burst of > 0.

This is an undocumented issue, but may be mentioned in a future version of the API / documentation.

Kudos to the tech support on this one.  A phone call resolved this much faster than emails back and forth.

We still need to put things through our stress tests, but so far things look very good.