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
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,
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!