Objective Development Forums

Re: Possible bug in V-USB

2015-12-15T06:13:47+02:00

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.

Statistics: Posted by ulao — Tue Dec 15, 2015 6:13 am

Re: Possible bug in V-USB

2009-08-24T12:27:16+02:00

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.

Statistics: Posted by christian — Mon Aug 24, 2009 12:27 pm

Re: Possible bug in V-USB

2009-08-23T17:04:23+02:00

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.

Statistics: Posted by Guest — Sun Aug 23, 2009 5:04 pm

Re: Possible bug in V-USB

2009-08-22T12:23:22+02:00

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

Code:

#define USBATTR_BUSPOWER        0x80
#define USBATTR_SELFPOWER       0x40
#define USBATTR_REMOTEWAKE      0x20

while USB 1.1 seems to define USBATTR_BUSPOWER as mandatory.

I'll change the driver accordingly. Thanks!

Statistics: Posted by christian — Sat Aug 22, 2009 12:23 pm

Re: Possible bug in V-USB

2009-08-21T20:25:07+02:00

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.

Statistics: Posted by Guest — Fri Aug 21, 2009 8:25 pm

Re: Possible bug in V-USB

2009-08-21T08:37:01+02:00

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

Statistics: Posted by mschoeldgen — Fri Aug 21, 2009 8:37 am

Re: Possible bug in V-USB

2009-08-13T10:43:48+02:00

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.

Statistics: Posted by christian — Thu Aug 13, 2009 10:43 am

Re: Possible bug in V-USB

2009-08-13T00:07:06+02:00

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,

Statistics: Posted by Guest — Thu Aug 13, 2009 12:07 am

Re: Possible bug in V-USB

2009-08-11T13:00:47+02:00

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

Thanks for the quick response.

Greetings!

Statistics: Posted by Michael — Tue Aug 11, 2009 1:00 pm

Re: Possible bug in V-USB

2009-08-09T21:04:16+02:00

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:

Code:

unstuff6:
    andi    x2, USBMASK ;[03]
    ori     x3, 1<<6    ;[04] will not be shifted any more
    andi    shift, ~0x80;[05]
    mov     x1, x2      ;[06] sampled bit 7 is actually re-sampled bit 6
    subi    leap, 3     ;[07] since this is a short (10 cycle) bit, enforce leap bit
    rjmp    didUnstuff6 ;[08]

Code:

unstuff6:
    andi    x2, USBMASK ;[03]
    ori     x3, 1<<6    ;[04] will not be shifted any more
    andi    shift, ~0x80;[05]
    mov     x1, x2      ;[06] sampled bit 7 is actually re-sampled bit 6
    subi    leap, -1    ;[07] total duration = 11 bits -> subtract 1/3
    rjmp    didUnstuff6 ;[08]

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.

Statistics: Posted by christian — Sun Aug 09, 2009 9:04 pm