How to fix "Error -5" when transmitting a random number of bytes using LIB-USB?

Question

I have a problem with a USB project using LIB-USB . The USB device is based on the PIC18F4550 and has a single control endpoint. The PC interface is written in MSVC and uses Lib-Usb 1.12.

At the end of the PC, the program starts by setting the configuration, submitting a request to the interface, and then sending (and receiving) control messages (vendor-specific), all successfully. After a random number of bytes has been transferred (somewhere between 100 and 2000), the transfer stops with the rc = -5 error returned from the usb_control_msg call.

At the PC end, the calls are as follows:

 ret = usb_set_configuration(udev, 1); ret = usb_claim_interface(udev, 0); ret = usb_control_msg(udev, USB_TYPE_VENDOR|USB_RECIP_DEVICE, CMD_RESET, 0, 0, buffer, 0, 100); ret = usb_control_msg(udev, 0xC0, GET_FIFO_DATA, 0, 0, buffer, 8, 100); 

The last call, which actually receives data from the USB device, is made many times in a row, but always dies after a random number of bytes (from 100 to 2000 in total). Changing the pipe to EP1 does the same with the same error that ultimately appears.

On a USB device (PIC), the end of the descriptor is very simple, it has only the EP0 channel and looks like this:

 Device db 0x12, DEVICE ; bLength, bDescriptorType db 0x10, 0x01 ; bcdUSB (low byte), bcdUSB (high byte) db 0x00, 0x00 ; bDeviceClass, bDeviceSubClass db 0x00, MAX_PACKET_SIZE ; bDeviceProtocol, bMaxPacketSize db 0xD8, 0x04 ; idVendor (low byte), idVendor (high byte) db 0x01, 0x00 ; idProduct (low byte), idProduct (high byte) db 0x00, 0x00 ; bcdDevice (low byte), bcdDevice (high byte) db 0x01, 0x02 ; iManufacturer, iProduct db 0x00, NUM_CONFIGURATIONS ; iSerialNumber (none), bNumConfigurations Configuration1 db 0x09, CONFIGURATION ; bLength, bDescriptorType db 0x12, 0x00 ; wTotalLength (low byte), wTotalLength (high byte) db NUM_INTERFACES, 0x01 ; bNumInterfaces, bConfigurationValue db 0x00, 0xA0 ; iConfiguration (none), bmAttributes db 0x32, 0x09 ; bMaxPower (100 mA), bLength (Interface1 descriptor starts here) db INTERFACE, 0x00 ; bDescriptorType, bInterfaceNumber db 0x00, 0x00 ; bAlternateSetting, bNumEndpoints (excluding EP0) db 0xFF, 0x00 ; bInterfaceClass (vendor specific class code), bInterfaceSubClass db 0xFF, 0x00 ; bInterfaceProtocol (vendor specific protocol used), iInterface (none) 

The actual structure is Bradley Mintch in assembly language.

If someone has encountered this type of problem before I want to hear about it, since I tried everything to solve the problem, including using a different channel (EP1 with the same results), check the UOWN bit on the PIC before recording to the pipe, setting communication with the host PC (where the PC must send a vendor-specific command before recording the dates), but to no avail.

Answer 1

Now it works!

Of course, now I feel "smart like a bag of hammers." If I read section 18 completely, I would notice a line about adding a 220nF capacitor between Vusb and ground. Added a 470nF cap between pin18 and ground, and that was all it needed ... reliable transmissions now.

Another case of "I forgot to read the fine print"

Answer 2

It is highly advisable to have a USB bus analyzer Lecroy and Ellisys are tall and a bit expensive. Total Phase is an example of a low end.
Using bus analyzers will help you write a lot of firmware and PC software if you can afford it. Using the analyzer, you can determine if there is a problem on your side of the PC (the data you read is on the bus, but you cannot see it in your software) or there is a problem in the implementation of your firmware (you do not see the data on the bus),

From your description it’s hard to understand what the problem is, and I don’t know what error -5 is, if you can post a definition name for this, I can be more useful.
In general, it is good practice to transfer data from / to the device with multiplication of the maximum packet size. I also suggest that you carefully read the relevant sections 5.5.3 (for control transfers) and 5.8.3 for mass transfers in the USB Specification

Additional comment based on the second journal :

The real error returned by the usb stack is in your log and its:
vendor_class_request(): request failed: status: 0xc0000001, urb-status: 0xc000000c

URB status (usb request block) defined in the usb.h Windows driver set as:
usb.h:#define USBD_STATUS_BUFFER_OVERRUN ((USBD_STATUS)0xC000000CL)

I found a good explanation for this error here .

Please ignore the fact that this is a specific WinDriver error, it simply overridden the error from Windows, and the explanation of what this usually means is correct.

Here is an example of why this might happen, but there are more potential reasons for this behavior.

Answer 3

I don’t have an analyzer (at least "at least), but I installed DebugView to see what the driver does, with the next output trace. The first transmission shown (vendor-specific) is successful, and the second dies. The return code is" -5 ", which means" I / O error "(not particularly useful), is returned from the call.

00002674 315.26220703 LIBUSB-DRIVER - vendor_class_request (): type: vendor
00002675 315.26223755 LIBUSB-DRIVER - vendor_class_request (): receiver: device
00002676 315.26223755 LIBUSB-DRIVER - vendor_class_request (): request: 0x04
00002677 315.26223755 LIBUSB-DRIVER - vendor_class_request (): value: 0x0000
00002678 315.26223755 LIBUSB-DRIVER - vendor_class_request (): index: 0x0000
00002679 315.26223755 LIBUSB-DRIVER - vendor_class_request (): size: 8 00002680 315.26226807 LIBUSB-DRIVER - vendor_class_request (): direction: to
00002681 315.26226807 LIBUSB-DRIVER - vendor_class_request (): timeout: 100
00002682 315.26617432 LIBUSB-DRIVER - vendor_class_request (): 8 bytes transmitted 00002683 315,26721191
00002684 315.26721191
00002685 315.26721191 LIBUSB-DRIVER - vendor_class_request (): Type: vendor
00002686 315.26721191 LIBUSB-DRIVER - vendor_class_request (): receiver: device
00002687 315.26724243 LIBUSB-DRIVER - vendor_class_request (): request: 0x04
00002688 315.26724243 LIBUSB-DRIVER - vendor_class_request (): value: 0x0000
00002689 315.26724243 LIBUSB-DRIVER - vendor_class_request (): index: 0x0000
00002690 315.26724243 LIBUSB-DRIVER - vendor_class_request (): size: 8 00002691 315.26724243 LIBUSB-DRIVER - vendor_class_request (): direction: in
00002692 315.26727295 LIBUSB-DRIVER - vendor_class_request (): timeout: 100
00002693 315.27017212 LIBUSB-DRIVER - vendor_class_request (): request failed: status: 0xc0000001, urb-status: 0xc000000c
00002694 315.27407837 [3684] LIBUSB_DLL: error: usb_control_msg: transmission of the control message failed, win error: the device connected to the system does not work.
00002695 315.27407837 [3684]
00002696 315.27511597
00002697 315.27514648 LIBUSB-DRIVER - release_interface (): interface 0