usbFunctionWrite incorrect length, need help

[baoshi]

Hi,

I'm trying V-USB on an ATmega328p board, using INT0 on D- (for USB suspend detection).
My project is modified from hid-data example, but I changed HID report size to 18 bytes. I wanted to test USB reliability so in the firmware side I simply copy the SET_REPORT 18 bytes buffer to a static buffer and return them for each GET_REPORT request. Because there are 18 bytes, I suppose the complete transmission should be split into 3 packets and each has 8-8-2 number of bytes.

The PC side is modified from hid-data commandline application on Windows 7/MingW, I generate 18 random bytes and send to the device, then get them back for comparison. The test is put in a while loop and I count how many iterations can be made without error.

The result appears to be not very solid. I will have an error on every 700-3000 loops randomly. When the error occurs, I can observe the length passed to usbFunctionWrite is not 8 or 2, but 6 (mostly) of the time or 7 (occasionally). This causes mismatch on the amount of data and host will think USB transaction to either stalled or cancelled.

I wonder if there are anything I can do to improve it.

TIA

[blargg]

Does the 328p board use a crystal oscillator or ceramic oscillator? I've got several 328p boards and they use ceramic resonators, which have lower accuracy and might cause occasional errors.

Also, you could enable CRC checking on the V-USB side, and have it at least ignore packets with incorrect CRCs. Put this in your usbconfig.h:

Code: Select all

#define USB_RX_USER_HOOK( data, len ) { \
    if ( usbCrc16( data, len + 2 ) != 0x4ffe )\
        return;\
}

[baoshi]

Totally make sense sir. Yes the board is using a murata 3pin ceramic oscillator.
I added CRC code and did DBG1 on every CRC error, it seems communication failure always occurred immediately after CRC error.
I'll find another board with crystal and test again.

Thanks!

Does the 328p board use a crystal oscillator or ceramic oscillator? I've got several 328p boards and they use ceramic resonators, which have lower accuracy and might cause occasional errors.

Also, you could enable CRC checking on the V-USB side, and have it at least ignore packets with incorrect CRCs. Put this in your usbconfig.h:

Code: Select all

#define USB_RX_USER_HOOK( data, len ) { \
    if ( usbCrc16( data, len + 2 ) != 0x4ffe )\
        return;\
}

[blargg]

That's too bad to hear. I got a bunch of those Deek-Robot atmega328p Arduino clones for $2 USD each recently and was hoping I could use some for V-USB reliably. I happened to also get a Baite version of this 328p board for only a little more and it seems to have a crystal oscillator (ceramic ones aren't accurate to 16.000 MHz):



Just in case you're trying to find some that will work.

[baoshi]

Thanks. Found it here.
http://www.aliexpress.com/store/product ... 85134.html

Nowadays these Chinese manufactures really keen on cutting cost. I get a recent Arduino Uno clone only to find they are also using ceramic resonate for the 328p, but when it is to the Atmega8U2, they used a crystal. They seems to know what they are doing

[blargg]

Here's the seller I got mine from for $2.46 individually shipped (mine was ePacket too for USA delivery, so faster and with tracking). http://www.ebay.com/itm/321454750990

BTW, the original Arduino 328p board used a resonator, so this Baite one is actually improving quality over the official board. I've gotten at least a dozen inexpensive clones of various boards and been impressed with the quality of all of them so far. One other change on this Baite board that I like is that the VCC on the side serial connector connects directly to VCC, rather than going through a reverse-current protection diode as on the green Deek-Robot boards, and thus dropping VCC unless you connect a separate supply to the side VCC pin.