Hi Thomas,

let me quickly address a few of these issues
On Tue, 2019-08-06 at 15:40 +0200, Thomas Fabricius via USRP-users
wrote:
> Hi,
> we have a number b210s that has USB detect problems. We have
> equipment where the power can suddenly disappear, and then the system
> does not come up right and there is (yet) no programmatic way to
> resolve the problem, so we have to get in physical contact with the
> system.
> Any one who knows of a workaround (pls. read below before answering)…
>  
> *PC cannot detect B210 USB device on cold boot (after for instance a
> power break)

I've seen that before on x86 industrial PCs. I think it might be a
combination of overtasked on-board USB voltage supplies and USB host
controller firmware.

> *The B210 USB device is simply not recognized by the PC.

That means it's not in `lsusb`?

> *The B210 has an attached GPSDO and external power attached.
> 

That at least rules out power supply problems.

> *This happens on multiple systems and cannot be attributed to a
> single PC type nor B210 device.

Ok, good to know!

>  
> Steps to reproduce:
> 1. Remove all power from PC and B210.
> 2. Insert USB into PC.
> 3. Apply power to the devices.
> 4. Start the PC.
> 5. The PC is after boot into linux to see the B210 board.
> 6. Errors are displayed in the dmesg kernel log:
>  

> [   23.884317] usb 1-4: new high-speed USB device number 3 using
> xhci_hcd [   29.024313] usb 1-4: device descriptor read/64, error
> -110 [   44.640330] usb 1-4: device descriptor read/64, error -110
> [   44.748356] usb usb1-port4: attempt power cycle [   45.400311] usb
> 1-4: new high-speed USB device number 4 using xhci_hcd [   56.240225]
> usb 1-4: device not accepting address 4, error -62 [   56.368230] usb
> 1-4: new high-speed USB device number 5 using xhci_hcd [   66.992306]
> usb 1-4: device not accepting address 5, error -62 [   66.992363] usb
> usb1-port4: unable to enumerate USB device
>  
> The "device descriptor read/64, error -110" means that USB power
> drain was exceeded by the USB device.

OK, is the external power supply you use the stock ettus one, or are
you using something different?

>  
> 7. Our application prints:
>  
> Error: LookupError: KeyError: No devices found for -----> Device
> Address:
>     num_recv_frames: 512
>  
> 8. The device is totally absent, so its not possible to for instance
> run:  $UHD_INSTALL_PREFIX/utils/b2xx_fx3_utils --reset-device
>  
> Workarounds that works:
> * Physically unplug the USB device and insert it again in the same
> USB port. (sometimes it though seems like this does not work either,
> and one need to switch to a new USB port on another USB HUB on the
> PC)

There's a high probability that means that some polyfuse has been
triggered, in my experience. I've seen that in systems where there was
no shared ground between USRP supply and PC, and the powering of either
device caused a significant inrush current (I guess, couldn't measure
back then).

>  
> * Physically press the reset switch (S700) on the B210.

That's interesting; s700 really fully resets the USB controller, but I
don't think the full board (would have to check).

>  
> * Remove external power supply from B210 before cold boot.

<-- that's the workaround I'd go for, see below.

>  
> Workarounds that haven't worked:
> * Rebooting the PC, by software and/or by physically switching it off
> and then on (power cable off and on).
>  
> * Try to programmatically remove power from USB device:
>  
>     lsusb
>     echo suspend > sudo tee /sys/bus/usb/devices/usb1/power/level
>     echo suspend > sudo tee /sys/bus/usb/devices/usb2/power/level
>     lsusb
>     echo on > sudo tee /sys/bus/usb/devices/usb1/power/level
>     echo on > sudo tee /sys/bus/usb/devices/usb2/power/level
>     lsusb
>  
> * Try to remove the highspeed USB driver:
>  
>     lsusb
>     echo "0000:00:14.0" | sudo tee
> /sys/bus/pci/drivers/xhci_hcd/unbind
>     lsusb
>     dmesg
>     echo "0000:00:14.0" | sudo tee /sys/bus/pci/drivers/xhci_hcd/bind
>     lsusb
>  
> * Remove and re-enumerate the USB controller PCI device:
>  
>     lsusb
>     lspci
>     echo 1 | sudo tee /sys/devices/pci0000\:00/0000\:00\:14.0/remove
>     lsusb
>     lspci
>     echo 1 | sudo tee /sys/bus/pci/rescan
>     lsusb
>     lspci
>  
Sad.

> Workarounds that haven't been tried:
> * Use an USB3 hub that is externally powered.
> * Install a larger capacitor in parallel with C716/S700 on the B210
> board to delay USB startup by the device. Somebody recall installing
> a 100uF capacitor. But this doesn’t seem like a root cause fix.

If its really about current draws, best guess is that this would
actually make it worse.

> * Circumvent power switching components (solder a short over Q600)
> such that external power is always used and not disconnected before
> any USB communication. Any side effects ?

Voiding a warranty.

What you could try: If you have a spare USB cable, gently circumsize
the plastic mantling in two places a couple cm apart, slice open the
mantling, find the red cable inside and cut it.

That would remove the 5V powering from the host. 
Haven't checked whether that works with the current firmware, though :(

>  
> Root cause:
> We believe the root cause is the switching between USB and external
> power, in the LTC4412 U609 circuit. If external power is removed
> before cold boot, the device comes up correctly while external B210
> power is not attached.
> Also worth noting, is that this may only happen when a GPSDO is
> attached. We haven't tried removing the GPSDO, since it is rather
> fragile.
> Another “malicious” behavior is when external power is on and USB is
> attached then Q600 will go on if it is not already on. When USB is
> removed Q600 will stay on, ie. the circuitry will not come back to
> the state it had when everything was powered on from scratch.
>  

Hm, yeah, the LED behaviour of Q600 was erratic for multiple customers
who had no other problems.

You don't happen to have an oscilloscope that you could attach to a
couple of power test points on the B200, trigger on edge, and see
whether this suspicion of yours works out to be right? 

Best regards,
Marcus


_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to