[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: USB device not accepting new address



Berland, Mathieu wrote:
> 
> Jan  1 00:02:26 AxisProduct kernel: usb-host.c: USB controller running.
> Jan  1 00:02:26 AxisProduct kernel: hub.c: USB new device connect on bus1/2,
> assigned device number 2
> Jan  1 00:02:27 AxisProduct kernel: usb-host.c: assert failed at line 1676
> Jan  1 00:02:27 AxisProduct last message repeated 4 times
> Jan  1 00:02:27 AxisProduct kernel: Manufacturer: CHANDER_2
> Jan  1 00:02:27 AxisProduct kernel: usb-host.c: assert failed at line 1676
> Jan  1 00:02:27 AxisProduct kernel: Product: USB tenkeypad2
> Jan  1 00:02:27 AxisProduct kernel: usb-host.c: assert failed at line 1676
> Jan  1 00:02:27 AxisProduct last message repeated 3 times
> Jan  1 00:02:27 AxisProduct kernel: hiddev0: USB HID v1.00 Keyboard [CHANDER_2
> USB tenkeypad2] on usb1:2.0

Slightly alarming; some control traffic may have been lost as the error 
message basically indicates that we're removing DMA descriptors for an 
active endpoint.

> Don't you think a USB 2.0 device is totaly compliant with the previous
> specifications ?

The device should be compliant; it's just that I don't know what happens 
electrically on the bus when it switches to/from high speed/full 
speed/low speed and how the HC handles it.

> Are the control frames electrically differents from the other ones ?

I don't think so.

> Can it be due to the PCB design of the USB transceiver ?

Could be.  The cases I've seen where device numbering fails were due to 
hardware issues.  But since things seem to work reasonably when you plug 
the HID device directly into the board's USB port, and just not when 
there's a hub in between, I don't know (it could be related to the speed 
mode switch).  I'd suggest checking voltage levels etc.  That could very 
well be the reason for the device not answering the device numbering 
request.

-- 
Orjan Friberg
Axis Communications