Re: [USRP-users] b210 USB detect problem
Hi Thomas, The switching **should** be really smooth! Also, it shouldn't confuse either USB end to stop working. But since we're really debugging this by now, this would be reasonable to check, yes. Do you happen to have an oscilloscope? By the way, does the device work with the Vcc-cut USB cable and external power? I've honestly never tried. Best regards, Marcus On Tue, 2019-08-06 at 21:23 +0200, Thomas Fabricius via USRP-users wrote: > Hi Marcus > > No detect = not in lsusb! > > The suspision is (more or less) confirmed: > Experiment 1: > -Starting from total power off and no USB cable: Led off > -Turn on PC: Led off > -Plug in USB cable: Led orange to indicate USB power > -Device is in lsusb list (ie. everything is good just from USB > power!) > -Plug in external power: Led change to blue indicating external power > -Unplug USB cable: Led stays blue > > Experiment 2: > -Starting from total power off and no USB cable: Led off > -Turn on PC: Led off > -Plug in external power: Led off > -Plug in USB cable: Led blue > -Device is in lsusb list > -Unplug USB cable: Led stays blue > > Experiment 3: > -Starting from total power off and no USB cable: Led off > -Turn on PC: Led off > -Plug in external power: Led off > -Plug in USB cable without power cord (cut as suggested): Led off > -Unplug USB cable: Led off > > Inrush can not be the problem, cause everything is fine just coming > up with USB power only, it though could be the switch-over to > external power ?!?!? > > /thomas > > > -Original Message- > From: Marcus Müller > Sent: Tuesday, 6 August 2019 17.39 > To: Thomas Fabricius ; usrp-users@lists.ettus.com > Subject: Re: [USRP-users] b210 USB detect problem > > 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; s70
Re: [USRP-users] Fwd: Configurating X300 "uhd_find_devices" No uhd devices found
Dear Edwin, this usually fails because the USRPs reply with a "where are USRPs broadcast" from uhd_find_devices with a "here I am broadcast", and often, these get caught in the firewall or don't get routed through e.g. NAT. Since you're using a VM: the X300 can push through a WHOLE lot of data per second. You'd typically really want to avoid that the host touches network data going to and coming from the VM for computational reasons. The most performant way to do that is to just bind your network card completely to the VM; as soon as you achieve that, the host can't filter out any replies anymore. You'll also need to make sure the VM's firewall doesn't either. Best regards, Marcus On Tue, 2019-08-06 at 17:40 -0500, Edwin Mauricio Barbosa Salinas via USRP-users wrote: > > > -- Forwarded message - > De: Edwin Mauricio Barbosa Salinas > Date: mar., 6 ago. 2019 a las 17:37 > Subject: Configurating X300 "uhd_find_devices" No uhd devices found > To: > > > regards, > I am currently working with a USRP X300, following its UHD and > GNURADIO installation guides, I am making the configurations from > Ubuntu 14.04 with a VM VirtualBox virtual machine, when I execute the > command "uhd_find_devices" it throws me a message saying "No UHD find > devices" but when I execute the command "uhd_find_devices --args =" > addr = 192.168.10.2 "" it executes it successfully, I want to know > how to do so that when executing the command "uhd_find_devices" it is > executed successfully. > > > root@edwin-VirtualBox:/home/edwin# uhd_find_devices > linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.005-0- > g32951af2 > > No UHD Devices Found > > root@edwin-VirtualBox:/home/edwin# uhd_find_devices -- > args="addr=192.168.10.2" > linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.005-0- > g32951af2 > > -- > -- UHD Device 0 > -- > Device Address: > type: x300 > addr: 192.168.10.2 > fpga: HGS > name: > serial: 3124ED5 > product: X300 > > > -- > Edwin Mauricio Barbosa salinas > Cod. 2172800 > INGENIERÍA DE TELECOMUNICACIONES > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Fwd: Configurating X300 "uhd_find_devices" No uhd devices found
-- Forwarded message - De: Edwin Mauricio Barbosa Salinas Date: mar., 6 ago. 2019 a las 17:37 Subject: Configurating X300 "uhd_find_devices" No uhd devices found To: regards, I am currently working with a USRP X300, following its UHD and GNURADIO installation guides, I am making the configurations from Ubuntu 14.04 with a VM VirtualBox virtual machine, when I execute the command "uhd_find_devices" it throws me a message saying "No UHD find devices" but when I execute the command "uhd_find_devices --args =" addr = 192.168.10.2 "" it executes it successfully, I want to know how to do so that when executing the command "uhd_find_devices" it is executed successfully. root@edwin-VirtualBox:/home/edwin# uhd_find_devices linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.005-0-g32951af2 No UHD Devices Found root@edwin-VirtualBox:/home/edwin# uhd_find_devices --args="addr=192.168.10.2" linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.005-0-g32951af2 -- -- UHD Device 0 -- Device Address: type: x300 addr: 192.168.10.2 fpga: HGS name: serial: 3124ED5 product: X300 -- *Edwin Mauricio Barbosa salinas* *Cod. 2172800* *INGENIERÍA DE TELECOMUNICACIONES* -- *Edwin Mauricio Barbosa salinas* *Cod. 2172800* *INGENIERÍA DE TELECOMUNICACIONES* ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] b210 USB detect problem
Oh forgot to tell, we do use the Ettus supplied external power supply! /thomas -Original Message- From: Marcus Müller Sent: Tuesday, 6 August 2019 17.39 To: Thomas Fabricius ; usrp-users@lists.ettus.com Subject: Re: [USRP-users] b210 USB detect problem 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 ":00:14.0" | sudo tee > /sys/bus/pci/drivers/xhci_hcd/unbind > lsusb > dmesg > echo ":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/pci\:00/\: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 com
Re: [USRP-users] b210 USB detect problem
Hi Marcus No detect = not in lsusb! The suspision is (more or less) confirmed: Experiment 1: -Starting from total power off and no USB cable: Led off -Turn on PC: Led off -Plug in USB cable: Led orange to indicate USB power -Device is in lsusb list (ie. everything is good just from USB power!) -Plug in external power: Led change to blue indicating external power -Unplug USB cable: Led stays blue Experiment 2: -Starting from total power off and no USB cable: Led off -Turn on PC: Led off -Plug in external power: Led off -Plug in USB cable: Led blue -Device is in lsusb list -Unplug USB cable: Led stays blue Experiment 3: -Starting from total power off and no USB cable: Led off -Turn on PC: Led off -Plug in external power: Led off -Plug in USB cable without power cord (cut as suggested): Led off -Unplug USB cable: Led off Inrush can not be the problem, cause everything is fine just coming up with USB power only, it though could be the switch-over to external power ?!?!? /thomas -Original Message- From: Marcus Müller Sent: Tuesday, 6 August 2019 17.39 To: Thomas Fabricius ; usrp-users@lists.ettus.com Subject: Re: [USRP-users] b210 USB detect problem 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
[USRP-users] Missing block controller warning in RFNoC
In another post, someone was mentioning the warning that is displayed if there is no block controller for a given rfnoc block. I would like to suggest that Ettus consider a different solution than providing this warning. Perhaps if the user could identify a block controller in the XML file (which would default to the block in question, but could be changed to any valid block controller), then the user could specifically choose the default controller for blocks that only need noc script (and thus no need for a warning if it is explicitly chosen). It would also allow the user to write a block controller that is common to several similar blocks, without mandating that the blocks have the same name. Rob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] E320 unable to lock to external reference
Thanks for the update Michael, I'll pass it along. Fingers crossed. From: Michael West Sent: Monday, August 5, 2019 4:49 PM To: Nate Temple Cc: Jason Matusiak ; Ettus Mail List Subject: Re: [USRP-users] E320 unable to lock to external reference We have someone looking into this now. In the meantime, try adding the device arguments "clock_source=external,time_source=external". Regards, Michael On Tue, Jul 23, 2019 at 12:23 PM Nate Temple via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: Hi Jason, I'm fairly confident that this is just a software issue. Regards, Nate Temple On Tue, Jul 23, 2019 at 11:06 AM Jason Matusiak mailto:ja...@gardettoengineering.com>> wrote: Thank you Nate. Good to hear that it wasn't a screw up on our part. Do you have a gut as to whether or not it is a hardware or software issue? From: Nate Temple mailto:nate.tem...@ettus.com>> Sent: Tuesday, July 23, 2019 2:01 PM To: Jason Matusiak mailto:ja...@gardettoengineering.com>> Cc: Ettus Mail List mailto:usrp-users@lists.ettus.com>> Subject: Re: [USRP-users] E320 unable to lock to external reference Hi Jason, I've been able to recreate this and have filed an issue on our internal bug tracker and escalated as a high priority issue. I'm not able to provide any ETA on when we will have a fix for it, but hope it will be soon. I will follow up as soon as I have more information. Regards, Nate Temple On Tue, Jul 23, 2019 at 10:12 AM Jason Matusiak mailto:ja...@gardettoengineering.com>> wrote: Do you need anything from my side of things? From: Nate Temple mailto:nate.tem...@ettus.com>> Sent: Thursday, July 18, 2019 3:49 PM To: Jason Matusiak mailto:ja...@gardettoengineering.com>> Cc: Ettus Mail List mailto:usrp-users@lists.ettus.com>> Subject: Re: [USRP-users] E320 unable to lock to external reference Hi Jason, This might be a bug with the E320. I will need to try to recreate this issue. I'll follow up as soon as I have more info. Regards, Nate Temple On Thu, Jul 18, 2019 at 12:32 PM Jason Matusiak via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: OK, we've been fighting this for a while and we think we narrowed it down to being a problem with the E320 (NOTE: we are running the E320 in network mode, not embedded) Some background: 1) external reference input is from an octo clock (so it the 1pps input) on many different ports a) also tried to use a Symmetricom box for external reference and had the same problems 3) the same code we are testing with works when using an x310 instead of an e320, with inputs from the same octoclock 4) the code basically does this: a) sets the reference source to external b) checks to see if the reference is locked (and it keeps doing this until we get a "locked" response, using the uhd commands to do this) 5) for the e320, the locked status never returns (when running the x310 with this code, it sometimes responds with unlocked, but after a few checks it comes back ok) 6) I tried some of the Ettus (UHD) test code a) running the "sync_to_gps" program did work - the reference was able to lock to the internal (gps) reference b) "test_clock_synch" returns similiar errors to what we get with our program (see below): Checking USRP devices for lock. * 318B08B: false WARNING: One or more devices not locked. Querying Clock for time and setting USRP times... [WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTRL reg: 0x0002 Running 10 comparisons at random intervals. Comparison #1 * Clock time: 1563463644 * 318B08B time: 1563463644 Comparison #2 * Clock time: 1563463652 * 318B08B time: 1563463652 Comparison #3 * Clock time: 1563463657 * 318B08B time: 1563463657 Comparison #4 * Clock time: 1563463664 * 318B08B time: 1563463664 Comparison #5 * Clock time: 1563463666 * 318B08B time: 1563463666 Comparison #6 * Clock time: 1563463671 * 318B08B time: 1563463671 Comparison #7 * Clock time: 1563463676 * 318B08B time: 1563463676 Comparison #8 * Clock time: 1563463686 * 318B08B time: 1563463686 Comparison #9 * Clock time: 1563463689 * 318B08B time: 1563463689 Comparison #10 * Clock time: 1563463691 * 318B08B time: 1563463691 Number of matches: 10/10 7) we ran the same tests at a sister site that has four E320s, and they all exhibited the same issues 8)Finally, a uhd_usrp_probe command returns this: [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36); Boost_105300; UHD_3.14.1.0-9-g2aa5289d [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.3,type=e3xx,product=e320,serial=318B08B,claimed=False,addr=192.168.10.3 [WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTRL reg: 0x0002 ... many of these warnings repeating ... [WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTR
Re: [USRP-users] b210 USB detect problem
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 ":00:14.0" | sudo tee > /sys/bus/pci/drivers/xhci_hcd/unbind > lsusb > dmesg > echo ":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/pci\:00/\: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
[USRP-users] b210 USB detect problem
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) *The B210 USB device is simply not recognized by the PC. *The B210 has an attached GPSDO and external power attached. *This happens on multiple systems and cannot be attributed to a single PC type nor B210 device. 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. 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) * Physically press the reset switch (S700) on the B210. * Remove external power supply from B210 before cold boot. 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 ":00:14.0" | sudo tee /sys/bus/pci/drivers/xhci_hcd/unbind lsusb dmesg echo ":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/pci\:00/\:00\:14.0/remove lsusb lspci echo 1 | sudo tee /sys/bus/pci/rescan lsusb lspci 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. * 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 ? 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. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] cmake error : Cross-Compiling GNU Radio on Ubuntu 16.04
Hi, I built the UHD and GRC with no error for a E310 as follow the updated procedure. Next I will try to build for E320 and Custom FPGA design. Thank you. Regards, ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] RFNoC Issue with 32 Bit Axi Stream | Error in Concat to 64 Bit | VHDL
Hello together, recently i started RFNoC development using an USRP x310. After finishing the RFNoC getting started Guide i created an OOT Module including VHDL. First i simply forwarded the Input Data to the output which worked just fine. After that i wanted to add a constant, for example 5_dec., to my signal (32 Bit) and receive the sum as an output in the testbench. Here the problems started: Instead of receiving 5,6,7,8,9 for input of 0,1,2,3,4; i got 5+2^32+2^34 6+2^32+2^34 7+2^32+2^34 etc. I figured out, that i got the right results in 32 Bit, but that somewhere in the axi_wrapper and/or the noc_shell my results gets concatted to 64 Bit, always using the first result (here the number 5) as the 32 msb's and the actual sum results as the lsb's thus changing my signal. Wondering, i tested some more stuff like just setting the lowest bit of 32 Bit input Data Vector to one etc. and get the same problems of wrong vector connections. Only when i changed the width parameter of the axi_wrapper to 64 Bit (and also sending 64 Bit Data) i got the expected results. Now my question: Is this a bug or am i maybe using the axi_wrapper wrong? I could not find an error comparing my code to the one of the tutorial_gain block. Any help to understand this is appreciated. Sincerly Felix ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
