[Solved] USB not working in WNR3500L V1 17.01.4

I just installed LEDE on my WNR3500L V1. Everything works well, apart from the USB port. After many tests, I narrowed down the issue to LEDE code, not the router. USB works in the Netgear firmware, and USB is powered at boot.

I installed LEDE Reboot 17.01.4 r3560-79f57e422d / LuCI lede-17.01 branch (git-17.290.79498-d3f0685) over the Netgear firmware, and have not updated LEDE (since there's no new build)

It looks as if during the boot process (very close to the end), the USB port gets powered down. I can measure the 5V on the USB port if I boot in failsafe mode, and during part of the boot process for the full LEDE boot. Towards the end, I can see 5V disappear.

I opened the router and I can see that there's a dedicated power chip for the USB port. The enable pin for that chip is 3.3V while booting and when in failsafe mode. Towards the end of the boot process I can see the pin go to 0V, and the USB port is de-powered

I have the packages listed below installed, and "lsusb -t" shows the USB bus working:

root@LEDE:~# lsusb -tt
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/2p, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/2p, 480M

but since the USB port itself is powered down, no USB device is recognized

What can I do to help narrow down what causes the USB bus to power down?

root@LEDE:~# opkg list
base-files - 173.1-r3560-79f57e422d
block-mount - 2017-06-30-bdcb075f-1
busybox - 1.25.1-4
dnsmasq - 2.78-1
dropbear - 2017.75-2
fdisk - 2.29.2-1
firewall - 2017-05-27-a4d98aea-1
fstools - 2017-06-30-bdcb075f-1
fwtool - 1
hostapd-common - 2016-12-19-ad02e79d-6
ip6tables - 1.4.21-2
iptables - 1.4.21-2
iw - 4.9-1
iwinfo - 2016-09-21-fd9e17be-1
jshn - 2017-02-24-96305a3c-1
jsonfilter - 2016-07-02-dea067ad-1
kernel - 4.4.92-1-54693f1dab3152ccbd607a9ef5836dab
kmod-b43 - 4.4.92+2017-01-31-3
kmod-cfg80211 - 4.4.92+2017-01-31-3
kmod-crypto-crc32c - 4.4.92-1
kmod-crypto-hash - 4.4.92-1
kmod-fs-exfat - 4.4.92+2017-01-03-8d291f525ce6d88fe0d8b11b86fd5c2e900401d3-1
kmod-fs-ext4 - 4.4.92-1
kmod-fs-msdos - 4.4.92-1
kmod-fs-vfat - 4.4.92-1
kmod-gpio-button-hotplug - 4.4.92-2
kmod-ip6tables - 4.4.92-1
kmod-ipt-conntrack - 4.4.92-1
kmod-ipt-core - 4.4.92-1
kmod-ipt-nat - 4.4.92-1
kmod-leds-gpio - 4.4.92-1
kmod-ledtrig-default-on - 4.4.92-1
kmod-ledtrig-netdev - 4.4.92-1
kmod-ledtrig-timer - 4.4.92-1
kmod-lib-crc-ccitt - 4.4.92-1
kmod-lib-crc16 - 4.4.92-1
kmod-mac80211 - 4.4.92+2017-01-31-3
kmod-nf-conntrack - 4.4.92-1
kmod-nf-conntrack6 - 4.4.92-1
kmod-nf-ipt - 4.4.92-1
kmod-nf-ipt6 - 4.4.92-1
kmod-nf-nat - 4.4.92-1
kmod-nls-base - 4.4.92-1
kmod-nls-cp437 - 4.4.92-1
kmod-nls-iso8859-1 - 4.4.92-1
kmod-nls-utf8 - 4.4.92-1
kmod-ppp - 4.4.92-1
kmod-pppoe - 4.4.92-1
kmod-pppox - 4.4.92-1
kmod-scsi-core - 4.4.92-1
kmod-slhc - 4.4.92-1
kmod-usb-bcma - 4.4.92-1
kmod-usb-core - 4.4.92-1
kmod-usb-ohci - 4.4.92-1
kmod-usb-ssb - 4.4.92-1
kmod-usb-storage - 4.4.92-1
kmod-usb-storage-extras - 4.4.92-1
kmod-usb2 - 4.4.92-1
lede-keyring - 2017-01-20-a50b7529-1
libblkid - 2.29.2-1
libblobmsg-json - 2017-02-24-96305a3c-1
libc - 1.1.16-1
libfdisk - 2.29.2-1
libgcc - 5.4.0-1
libip4tc - 1.4.21-2
libip6tc - 1.4.21-2
libiwinfo - 2016-09-21-fd9e17be-1
libiwinfo-lua - 2016-09-21-fd9e17be-1
libjson-c - 0.12.1-1
libjson-script - 2017-02-24-96305a3c-1
liblua - 5.1.5-1
libmount - 2.29.2-1
libnl-tiny - 0.1-5
libpthread - 1.1.16-1
librt - 1.1.16-1
libsmartcols - 2.29.2-1
libubox - 2017-02-24-96305a3c-1
libubus - 2017-02-18-34c6e818-1
libubus-lua - 2017-02-18-34c6e818-1
libuci - 2016-07-04-e1bf4356-1
libuci-lua - 2016-07-04-e1bf4356-1
libuclient - 2017-09-06-24d6eded-1
libusb-1.0 - 1.0.21-1
libuuid - 2.29.2-1
libxtables - 1.4.21-2
logd - 2017-03-10-16f7e161-1
lua - 5.1.5-1
luci - git-17.290.79498-d3f0685-1
luci-app-firewall - git-17.290.79498-d3f0685-1
luci-app-samba - git-17.336.23170-d2dc32a-1
luci-base - git-17.290.79498-d3f0685-1
luci-lib-ip - git-17.290.79498-d3f0685-1
luci-lib-jsonc - git-17.290.79498-d3f0685-1
luci-lib-nixio - git-17.290.79498-d3f0685-1
luci-mod-admin-full - git-17.290.79498-d3f0685-1
luci-proto-ipv6 - git-17.290.79498-d3f0685-1
luci-proto-ppp - git-17.290.79498-d3f0685-1
luci-theme-bootstrap - git-17.290.79498-d3f0685-1
mount-utils - 2.29.2-1
mtd - 21
netifd - 2017-01-25-650758b1-1
nvram - 10
odhcp6c - 2017-01-30-c13b6a05-2
odhcpd - 2017-10-02-c6f3d5d4-2
opkg - 2017-03-23-1d0263bb-1
otrx - 1
ppp - 2.4.7-11
ppp-mod-pppoe - 2.4.7-11
procd - 2017-08-08-66be6a23-1
rpcd - 2016-12-03-0577cfc1-1
samba36-server - 3.6.25-8
swconfig - 11
ubox - 2017-03-10-16f7e161-1
ubus - 2017-02-18-34c6e818-1
ubusd - 2017-02-18-34c6e818-1
uci - 2016-07-04-e1bf4356-1
uclient-fetch - 2017-09-06-24d6eded-1
uhttpd - 2017-08-19-3fd58e9b-1
uhttpd-mod-ubus - 2017-08-19-3fd58e9b-1
usbutils - 007-7
usign - 2015-07-04-ef641914-1
wpad-mini - 2016-12-19-ad02e79d-6

You might start with the USB Troubleshooting section of the LEDE User Guide...


Thanks, but I ran all the troubleshooters and those don't help any. All the packages are installed, and I can see the USB hub.

Believe me, I searched every forum for possible ideas, and tried just about anything software-wise. There is nothing about USB ports not being powered as a result of installing LEDE.

I can selectively remove packages and see which one triggers the problem. It must be a package or a component, since failsafe mode keeps the USB port powered. So it's something loaded on top of the barebone failsafe environment that causes the problem. I simply do not know where to start, and I can't try removing random packages because I risk having a non-bootable environment as a result.

I'm hoping that someone familiar with the USB subsystem or the WNR3500L can point me in the right direction

There is this:
but no resolution there.
The simplest thing may be to lift the pin on the USB power chip from whatever in the router is controlling it, and strap it to always be on.
Almost always these chips are wired to a GPIO pin on the CPU so it doesn't make a lot of sense it would be linked to the wireless.

I'll be darned, that one I did not find in my searches :slight_smile:

I'll try to see if enabling wireless is what causes the problem, just to narrow it down. And as much as I don't like modifying the hardware to fix a software problem, you might be right in suggesting that option as a workaround, even if lifting that pin risks ruining the PCB, given the location

Would it help if I managed to figure out what GPIO pin it might be? Is there any interest in actually fixing the bug in the code?

Some more progress: disabling wireless makes no difference

Yesterday I tried playing with GPIOs (wiki doc hardware port.gpio), and created the gpiocontrol.sh shell file. I tried setting all existing GPIOs from 8 to 15 to high (1), saw that the USB power came up (yay!), started turning them off one by one, and GPIO 12 controls the USB power. I was able to turn it on and off a few times. I mounted a USB drive, everything worked. The only weird thing is that the setting persisted over reboots (i.e. all GPIOs were on, no matter what). Then, since I had seriously messed up my config over time ad to reset the other GPIOs, I stupidly decided to reset to factory settings the router.

After doing it (and recreating gpiocontrol.sh), I tried turning on GPIO 12, but nothing. No matter what I do, it always stays 0. Any pointer to why, on a clean system, I cannot turn on GPIO 12? It's recognized and I can read it, but it always reads 0

As a side note, very likely the bug can be solved by setting GPIO 12 on boot...

More updates. If I factory reset and do not enable wireless ever, USB is powered, and all GPIO commands work as expected:

echo 12 > /sys/class/gpio/export
cat /sys/class//gpio/gpio12/value
echo out > /sys/class/gpio/gpio12/direction
echo 1 > /sys/class/gpio/gpio12/value

turns on USB, and echo 0 > /sys/class/gpio/gpio12/value turns it off

Once wireless is enabled, gpios stop working as expected. The commands above do not change the value of the pins. echo 1 > /sys/class/gpio/gpio12/value followed by cat /sys/class//gpio/gpio12/value, results in reading back 0 (and USB is not powered)

Looking around, I found: http://svn.dd-wrt.com/changeset/12966, which shows that the problem has been fixed in other builds ot open software

Final update: it is indeed a NVRAM configuration issue, as per the changeset in dd-wrt

all I had to do was

nvram set boardflags=0x00000710
nvram commit

followed by a power cycle (reboot is not enough). After that USB has power and everything works as expected