You are here

Determination of USB Transfer Quality | Cypress Semiconductor

Determination of USB Transfer Quality

Summary: 3 Replies, Latest post by GreenOnion on 23 Oct 2015 12:10 AM PDT
Verified Answers: 0
Last post
Log in to post new comments.
GreenOnion's picture
4 posts

Dear Cypress Community,

We are working with Fx2-device CYC68013A and also using the latest Cyusb3 driver package.
The driver communication is done via IOCTL functions.
Sometimes we have to deal with noisy environment where EMI-sources might have a significant impact to the USB signal quality.

On the low-level site, every transfer is normally stuffed by a couple of different status informations like Framing-Errors/CRC-Error/Ack-Errors,...a.s.o.
(like the USBD-status as denoted in the USB2.0 specification).
Additionally there are also error counter available which are incremented after a transfer fails.
These informations will be highly interesting if you have to evaluate EMI and cable quality issues.

Now the question:
Are there any possibilities to readout this (low-level) informations from the driver or are there other possible sources (API-functions to access the USB-host driver status,...)
which will provide the low level transfer status?

p.s.: The USBD status which is part of the "Single_Transfer" structure in the CyUSB driver shows always zero .I think this is normal since an overlapped transfer call return always immediately with IO_PENDING and there is no other possibility to get dedicated informations about the usbdstatus/ntstatus while using the DeviceIOControl-function.


Thanks in advance,


mady's picture
Cypress Employee
964 posts


You can read the upper nibble of ERRCNTLIM  register to track the Low level error counts. Please refer the TRM for more details.


- Madhu Sudhan

GreenOnion's picture
4 posts

Dear Madhu,

Thanks a lot for the response. To monitor the ERRCNTLIM register is a great idea but will only work as long as the USB transfer to the host application is valid. If the driver (or HUB-hardware) terminates the connection caused by massive transfer problems, there is no chance to readback the ERRCNTLIM register anymore. Therefore I was looking for some detailed informations from the driver-side after a connection has been disabled. There are still some informations available after DeviceIO() calls and also from GetLastError() but they are picked from the Windows standard system error code table and often very global (like: ERROR_NOT_READY). Normally the USBD_STATUS is exactly that what I need but as denoted in my first post, they are always zero after a DeviceIO() call.

Anyway, your proposal is very good and I will implement this in addition to track potential EMI issues.

One more question:

What happen if the ERRCNTLIM  register reaches its maximum value? Is there just the <USB Error Limit> interrupt generated (for application information only, without any further consequences) or will the controller-SIE enter an error state and stop serving the USB ?

I couldn't really find any additional informations regarding this in the TRM.

Thanks a lot for support & best regards,



GreenOnion's picture
4 posts

Hi Madhu,

The issue I had with the USBD_STATUS always zero in the TSINGLE_TRANSFER_SETUP is now solved. It was my fault because the pointer to the record was local in the function where I call the DeviceIO() and therefore no longer valid after exit the function. Now it is global and works like expected!

Thanks again for support!


Log in to post new comments.