USB error codes

[Rusttree]

After plugging my 18f14k50 into the USB port of my Linux box, I get these messages in dmesg:

usb 2-3: new low speed USB device using ohci_hcd and address 30
usb 2-3: device descriptor read/64, error -62
usb 2-3: device descriptor read/64, error -84

Does anyone know if these are error codes specified in the standard, unique to the Linux kernel, or something else entirely? I'm having a heck of a time finding a lookup table that describes what "error -62" and "error -84" are. The USB spec doesn't seem to mention them and google searches have been fruitless so far.

Thanks,
Dan

 

[Pommie]

I don't know what the messages mean but it looks like your descriptor is wrong. Can you post your descriptors?

Mike.

 

[Rusttree]

Sure. Please excuse my horrifically bad practice of initializing each individual byte as "unsigned char __at....". I was experimenting with RAM access and that's what I came up with at the time. I'll clean it up once I get the basic USB functionality working. Here's the 18 bytes of my device descriptor:

unsigned char __at (0x2BF) BYTE2BF = 18;      // size of descriptor in bytes
unsigned char __at (0x2C0) BYTE2C0 = 1;       // device descriptor code
unsigned char __at (0x2C1) BYTE2C1 = 0x02;    // USB 2.0 (lsb)
unsigned char __at (0x2C2) BYTE2C2 = 0x01;    // USB 2.0 (msb)
unsigned char __at (0x2C3) BYTE2C3 = 0;       // class code 
unsigned char __at (0x2C4) BYTE2C4 = 0;       // sub-class code 
unsigned char __at (0x2C5) BYTE2C5 = 0;       // protocol code 
unsigned char __at (0x2C6) BYTE2C6 = 64;      // Max packet size 
unsigned char __at (0x2C7) BYTE2C7 = 0xB4;    // Vendor HTC (lsb)
unsigned char __at (0x2C8) BYTE2C8 = 0x0B;    // Vendor HTC (msb) 
unsigned char __at (0x2C9) BYTE2C9 = 0x02;    // Product ID Android Phone (lsb)
unsigned char __at (0x2CA) BYTE2CA = 0x0C;    // Product ID Android Phone (msb) 
unsigned char __at (0x2CB) BYTE2CB = 0x01;    // release ID (lsb) 
unsigned char __at (0x2CC) BYTE2CC = 0x00;    // release ID (msb) 
unsigned char __at (0x2CD) BYTE2CD = 0x00;    // string descriptors
unsigned char __at (0x2CE) BYTE2CE = 0x00;    // string descriptors
unsigned char __at (0x2CF) BYTE2CF = 0x00;    // string descriptors
unsigned char __at (0x2D0) BYTE2D0 = 0x01;    // num configurations

As you can tell, I used the descriptor message from my Android phone as a template. I'm assuming the host can't possibly know this early on that it's not actually an Andriod phone...... can it?

 

[Pommie]

Haven't you got the USB version as 1.02? Shouldn't it be 0x00,0x02?

Mike.

 

[Rusttree]

I've actually tried it both ways. I wasn't sure if I had chosen the correct endian-ness, so I swapped every 2-byte value at one point or another. Do you now if USB hosts typically reject an incoming descriptor packet immediately if it doesn't like a value in it? I've been going on the assumption it collects all of the descriptors first before attempting to detect errors. That's why I'm using the vendor and product ID of my cell phone... and I haven't even written a driver yet.