GPIF, Bulk OUT, and Error Code: 997

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I have taken the slave fifo async example, and replaced the state machine with a much simpler state machine. The current GPIF state machine calls DR_DATA (reads from Thread3) in one state then calls DR_GPIO in another, there are no conditions, everything's LOGIC_ONE. By looking at a logic analyzer I see the appropriate GPIO pin is being toggled by DR_GPIO which makes me believe that the state machine is running. When I use the USB Control Center application on windows, I can send 2 large 1024 byte packets (whose DMA callbacks are received) after which the application is unable to send any more data and fails with the message "BULK OUT transfer failed with Error Code: 997". After this however the every BULK OUT fails, and the DMA callback on the FX3 is no longer called.

   

What causes this error to occur? Does the FX3 think the GPIF is not removing content from the DMA buffers fast enough (or at all)?

   

If so, how should I correct this in my simple state machine? I've tried switching DR_DATA between Thread0 and Thread3 to make sure I didn't mix up the threads.

0 Likes
4 Replies
Anonymous
Not applicable

 Alternatively, is there an example or suggested way for DMAing from a USB BULK OUT endpoint to sending the data out throuf h GIF? 

0 Likes
Anonymous
Not applicable

 After several days of experimenting with the GPIF bus on various boards, including the FX3 dev board I still not able to get GPIF port to execute a DR_DATA action correctly. The GPIF design is a simple, it uses a 16 bit bus in master synchronous mode. The design contains a single state with a toggle DR_GPIO and a DR_DATA reading from Socket: Thread3 (which I have verified as being the consumer thread used by the U2P DMA descriptors). I can see the GPIO pin toggling with every GPIF clock cycle.

   

Using the cyfxslfifoasync.c example to load this GPIF design file causes Error code 997 to appear after two 1024 byte transfers are sent, this made me think that the DMA buffers were not consumed by the GPIF bus. So I commented out the function calls to CyU3PDmaChannelSetXfer() to manually DMA CPU buffers to the GPIF. I added a call to CyU3PDmaChannelSetupSendBuffer(), which finishes with return status 0, followed by a loop to check to see when the channel moves away from status CY_U3P_DMA_PROD_OVERRIDE, however the channel never does, and the consumer byt e count stays at the original 1024 bytes. According to the documentation, CY_U3P_DMA_OVERRIDE means the DMA transfer is ongoing, however it never finished and nothing ever appears on the GPIF data lines, the GPIO pin I set to toggle with DR_GPIO seems to toggle just fine during all of this.

   

From these two experiments it seems also as if the GPIF controller is not consuming buffers at all. 

   

Any help would be very greatly appreciated.

   

 

   

I'm also disheartened to see that there are no examples for a task a simple as writing data to the GPIF port in any of the examples or online documention. Has this functionality of the FX3 been verified? If so, how?

   

Could Cypress please comment on this?

0 Likes
Anonymous
Not applicable

 Apparently the simplest test scenarios sometimes are the ones that don't work. After making an entire state machine that knows when to call DR_DATA everything started working. This makes it seem the timing of DR_DATA is essential otherwise the state machine can enter a weird state.

0 Likes
Anonymous
Not applicable

i met the problem too, how is the solution for this case?

   

Why no Cypress comment?

0 Likes