USB superspeed peripherals Forum Discussions

We are using the Cypress example code SlaveFifoSync. The demonstration host application GUI USB Control center works fine with our FPGA design for single transactions. 
We have developed a host side application in C++ that exercises the API XferData() method function for reads and writes (each from the appropriate handle). 
We have also connected to the Cypress card over a serial link in order to observe output of the CyU3PDebugPrint that the firmware source code is instrumented with. 
What we initially observe on the firmware console debug are messages that appear at 1 second intervals that confirm that the firmware is in good working order. 
When we run our host application which comprises a sequence of calls to XferData() for reads and writes (to CSRs in our FPGA design) is that a varying number of these complete successfully and then there is an apparent hang where some access never completes. On the debug console, the messages emitted at 1 second intervals have stopped. 
We have further instrumented the firmware source code with CyU3PDebugPrint and isolated a function that never seems to return: 
status = CyU3PDmaChannelCommitBuffer(chHandle, input->buffer_p.count, 
0); 
We have also attached a logic analyzer on the slave bus between the Cypress card and the FPGA and observed that expected transactions are not appearing at the interface when we expect Cypress to drive the bus. 
We have found that introducing a delay (Sleep()) of 100 milliseconds into the host application after each call to the Cypress API XferData is sufficient to cause all the host generated accesses to proceed normally. We have observed that a delay of 10 milliseconds is insufficient. 
That we need to pace the host application to workaround an apparent firmware issue is unacceptable. Our application requirements for full speed application cannot tolerate even a delay of 10 milliseconds. What we want is a stable, production ready code that implements the functionality of SlaveFifoSync at full speed. 


We assume that customers using this chip in production must be using a fullspeed version of this firmware - please let us know if we can have access to this or if the expectation is for us to somehow develop our own. 

Hello,

I have setup appropriate usb descriptors for interrupt endpoint and PC can detect it as the control center shows everything as expected. When I am sending the data from pc, I am not sure how to extract it in the firmware. Which event shall I expect and which api need to be used to get the data? Can anybody point me to the example or documentation?

Regards.

It will just stop sending data to the host after some time (minutes).

Most of the time i get "Error in multichannelcommitbuffer: Code = 71, size = 3FFF, dmaDone 0-7" error, but sometimes it just stops outputting frames without it (the COM port stops printing the frame numbers, i've even made it just output + or - instead of full frame number in case that was delaying the CPU enough to break it, but no.). Sometimes it is enough to just disconnect/reconnect the video stream in virtualdub/OBS, sometimes the ARM cpu needs a reboot to fix the stall.

And sometimes it does this: https://images.sshnuke.net/2016-01-04_00-38-57.png the clear feature request was initiated by me to try and re-start it, but now its stuck and requires a reboot.

The example is exactly the code with the AN, i just set 32bits to true in the C code, then in the GPIF2 editor made the requested modifications for 32bit operation: counter limits set to 4091. I've also modified the descriptor for 720p60 operation.

The waveforms of FV and LV are as such: https://images.sshnuke.net/2016-01-04_00-41-06.png

FV goes high at the same time as first LV does, to give the ARM CPU as much time to reset DMA and state machine as possible (it is 407uS of LOW value of FV in that screenshot)

This unstable behaviour is quite unacceptable for a 'complete' video solution...and you cannot really debug the GPIF2 state machine/DMA engine, just the ARM cpu, so how does this get fixed into a usable video device ? This is all in Release mode btw, not Debug.

EDIT: This is what it looks like when it requires a ARM reboot to get unstuck: https://images.sshnuke.net/2016-01-04_01-15-41.png

The 'backflow detect' feature does print backflow detected when it stops working, but does nothing to recover from the situation.

USB Analyzer screenshot of one of the situations: https://images.sshnuke.net/2016-01-04_09-13-03.png

It would seem that adding some more code to properly 'unstick' the DMA channels in the case the host could not consume all the data (so that the next frame keeps working) would make this example work properly.