Objective Development Forums

Hello V-USB community,

i spent a lot of time now, finding an error in my hard- software setup, but as it seems this might really be a bug in the V-USB firmware driver.

Under special conditions, I can reproduce an USB transmission error.

My Hardware Setup:
Atmega128 with 16 MHz crystal oscillator
Power supplied from USB, dropped to 3,6V with 2 series diodes.
D+ connected to PD0, Pin 25 (INT0)
D- connected to PD1, Pin 26

Firmware:
Is a stripped down version of the custom_class example and as simple as possible to reproduce the error.
1.) For incomming control transfers, the data payload gets saved in a buffer in ram
2.) For outgoing control transfers, the data from the buffer will be transmitted

Reproducing the error
I use a small command line tool, to test the usb connection.
1.) It starts a control transfer and sends a data packet which contains 200 bytes to the device. The device buffers the packet. Every byte of the packet has the same value.
2.) Then another control transfer is started and the buffered data is transfered from the device to host.

If the data packet contains the value 0xFE or 0x7E (200 times) a transmission error happens and step 1.) fails. The error only appears with those values, any other value can be sent without problems.

Following error sources have been ruled out already:
Configuration Errors (By using the custom_class example project as reference)
Hardware Problems (The signals on the bus lines have been checked with a scope and look clean)

I suspect some kind of synchronization error in the asm part of the driver.

All files to reproduce the error can be downloaded:
http://www.home.hs-karlsruhe.de/~bemi1012/usb_bug.zip

Can someone confirm this bug?

Greetings
Michael Betz

Has someone tried to reproduce the bug?

The only things you need are the files from the link in the previous post and any uC that can run V-Usb.

It is very strange that the error only happens with the data payload 0xFE / 0x7E, is it possible that the error is related to the bitstuffing routine in the 16 MHz asm part of the driver?

Unfortunately I don't have much experience in asm programming and in the usb protocoll on bit level.

If this bug can confirmed, a lot of bootloader projects would be affected.

Please post any thoughts here.

There is definitely a software bug in the 16 MHz asm part of the driver.

I just changed to a 12MHz crystal and anything works as it should, no transmission errors.

If you have built the UsbAsp - Loader, running at 16Mhz system clock, then you are affected by the bug.
To test this you can simply try to flash following .hex file over the bootloader:
http://www.home.hs-karlsruhe.de/~bemi10 ... shable.hex
AvrDude refuses to flash this file and will show a usb error.

OK, I can reproduce the problem.

It will take some time to analyze it, though...

Did not take THAT long to track down: The unstuffing code for bit 6 was ca. one cycle too long. The error summed up if multiple unstuffings occurred in bit 6 until we were out of sync.

You can fix the issue by changing the code in usbdrvasm16.inc:


to


The other unstuffing routines need a fix, too, but the error is not big enough to cause any problems when it sums up.

This will be fixed in the next release.

This fixes the bug, now the usb communication works like a charm.

Thanks for the quick response.

Greetings!

Hi,

I find the same problem with 20mhz.

The host enumerates de device properly, the `set-led' application can turn the led on, it can also get device's status, but as soon as I try to turn the led off, the usb_control_msg returns with an error (sometines the led is effectively turned off, sometimes not).

From there on, all I get when trying to do anything else is a protocol error from the same function, and I have to reconnect the device for it work again.

I have enabled the`test' option, though, and it passes it without a single error.

Regards,

This must be a different issue. I have tested the 20 MHz version with test patterns which enforce bit stuffing at always the same bit. I have tested all bits this way.

Thanks to Michael !
This fix finally got rid of the erratic coordinates i encountered with my Tablet Adapter :
viewtopic.php?f=8&t=2765
Initilally i though the tablet to be responsible for those errors. Thanks again

Hi,

It was indeed a different issue.

Remeber I was using the custom-class example shiphed with vusb? a lsusb for this device showed this message:

(Missing must-be-set bit!)

Then, I just set the topmost byte to one within usbdrv.c:

(1<<7) |
#if USB_CFG_IS_SELF_POWERED
USBATTR_SELFPOWER, /* attributes */
#else
(char)USBATTR_BUSPOWER, /* attributes */
#endif

And that was all!!

Now I can turn the led on, query the status, and turn it back off without getting a `protocol-error' message from the host.

Now everything works as expected, it works so reliably, can't understand why nobody else (which uses linux) was getting the same as me, though.

Thanks.

Thanks for the hint! USB 1.0 declared the bmAttributes field as with values

while USB 1.1 seems to define USBATTR_BUSPOWER as mandatory.

I'll change the driver accordingly. Thanks!

Hi,

You're wellcome.

What I read within the usb spec was that the topmost bit should always be set to one for historical reasons, that's what I found out after diging into that error from lsusb (which didn't notice at the time of my last post, but was also showing up on wireshark)

However, the trick lasted very little.

I'm still back to the same situation, where I can turn the led on, perform a read-stress test without failure, query it's status, but as soon as I turn the led back off, I get a "wrong multi-byte sequence" error, and from there on and till I replug the device, any request gets a "protocol error" message as answer.

This is something I've also noticed using usbtiny as well as vusb with different clock rates.

Strange is that with same hardware, I cun run the hid-mouse example without a problem (that one also shipped with vusb, which makes the pointer go in circles arround the screen).

It looks like as if some buffer weren't getting clean before the second request arrives or something like that.

Unfortunately, though I've been these last days reading up on usb, doesn't matter how many times I look at the code, I can't even get to understand how the first (KJKJKJKK, sync sequence) is achieved by carefully studying the assembler source!

It's getting a bit painful to get this up and running without any debugging form available other than a led! hehe.

Well, thanks.

We have released a new version of the driver yesterday. I doubt that it fixes your particular problem, though, since it fixes bugs in the 12.8 and 16 MHz modules only.

If the bugs occur with all clock frequencies, the problem must be in the common code, not in the low level bitbanging stuff. It's either in the concepts (buffer swapping, ACK/NAK handling) or in the usbdrv.c module. These are much easier to understand than the low level bitbanging.

In any case, you can enable debugging code by compiling with -DDEBUG_LEVEL=2. Debug output is sent through the USART at 19200 bps. To see what a particular debug print means, search usbdrv.c for DBG1 and DBG2 macros. The first parameter to the macro is the first hex number printed. There are debug logs for all received and all transmitted messages. Be careful, though: Transmitted messages are printed when they are written to the buffer, not when they are fetched by the host. If the transfer stalls, the last tx message may never have been fetched.

For fine grained debugging, I usually toggle port pins in particular positions and connect a storage scope.

Regards, Christian.

Not sure I follow this here but I'm getting this in linux.

Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 41
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x00
(Missing must-be-set bit!)
(Bus Powered)
MaxPower 224mA

This looks bad to me, why are we clearing the bit exactly? Or is linux using older code and reading as 1.0 instead of 1.1?

Sorry for the huge bump but it seem best to use this post.