Can anyone pinpoint because of what it might occur following described behavior ?
We are using FX3 (USB3.0) chip which gets connected with Linux PC where its device driver runs. As per project need, FX3 sends 2 byte data using DMA buffer (total 4 DMA buffers) on its interrupt end-point. However most of time host receives these data since it submits URB every time before FX3 generated interrupt data, sometime host doesn't get this data. While debugging at FX3 firmware code, it seems like it has successfully got the DMA buffer, copied the 2 byte data into this buffer and committed it without any failure. We couldn't see any failure on these APIs in firmware (CyU3PDmaChannelGetBuffer() & CyU3PDmaChannelCommitBuffer()), they always returns 0 i.e. Success.
Also, from host perspective, device-driver developer says that there is no issue in URB submission. We couldn't see any error in syslog.
While further testing, we could see that if host makes any single transaction on BULK-OUT EP (from host to FX3), this earlier committed (and stalled) interrupt now gets received by host. So we don't know what exact happens whether it gets blocked somewhere either in FX3 side or Host side.
So let me ask whether anyone has faced such thing or any idea on this, please let me know.
Could you please try to obtain the trace on Lecroy USB analyzer for failing case. Also are you able to reproduce the issue on Windows host machine?
Thanks & Regards
Thanks for reply.
At present I don't have proper windows code, but earlier it was same behavior with windows too.
Also, regarding USB analyzer, I need to find here if I get somewhere here.
Please attach the lecroy USB analyzer logs so that I can debug the issue.
Thanks & RegardsAbhinav Garg
As we dont have any usb analyzer (hardware device), so not possible to forward the log at present.
For the time being you can use USB bushound software to capture USB traces. Please check if there is any differences in both passing and failing cases.
Thanks & Regards
Already I've tried with 'wireshark' and found that host remains ready to capture response from device as I could see that it send request on Interrupt EP, but somehow it couldn't receive any response against this submission.
But strange is if I restart the pane by one button on the wireshark screen, that device sent interrupts gets received. Also similar behavior I mentioned in my top message - "While further testing, we could see that if host makes any single transaction on BULK-OUT EP (from host to FX3), this earlier committed (and stalled) interrupt now gets received by host.".
What is the size of the DMA buffer?
-- While further testing, we could see that if host makes any single transaction on BULK-OUT EP (from host to FX3), this earlier committed (and stalled) interrupt now gets received by host.
After host makes any single transaction on BULK-OUT EP, will the streaming resumes or you receive only one last stalled data?
Are you able to see any multiple retries due to data corruption? If yes then you have to check for the CYU3P_USBEP_SS_RESET_EVT in FX3 firmware and handle the same.
Thanks & Regards
I've registered this callback - CyU3PUsbRegisterEpEvtCallback (Fx3EpCallback, 0x1B0, 0x00, 0x07); where my interrupt EP is 0x82.
But it never hit this callback.
Now let me tell more on my further debug: ultimately it fails for some slower interrupt from device. So as per my first post here, initially it works for some number of interrupts, but when last interrupt where it stuck is somewhat slower than earliers. Now If I put ''bInterval" value in interrupt descriptor as some higher like 0x0B instead of earlier 0x04, host can retrieve this interrupt !!! But if I make value less than 0x0B, then this slow interrupt doesn't retrived by host.
Do you have any idea which fx3 registers should I read to know exact whether host is missing interrupt-request to send or device is behaving wrong even after getting interrupt-request from host by sending just NACK back even already queued DMA data it has ??
Please find my comments below:
But if I make value less than 0x0B, then this slow interrupt doesn't retrived by host.
>> Do you mean that when bInterval value is increased the interrupt endpoint works fine and data is received by the host?
If yes, for Interrupt IN transfer please check the USB trace to understand that the request is sent by the host. Also try increasing the timeout period from the host application. Please check the return status of the USB interrupt transfer on the host side for failure case
Also, please check that device doesn't go to Low power mode by calling CyU3PUsbLPMDisable() in CY_U3P_USB_EVENT_SETCONF