Short version: What is the most likely hardware failure that would prevent the USB ports from being powered, the GPIO UART pins from working at all, and the WiFi chipset from being initialized, without affecting the HDMI/SD/CPU?


I connected a (fresh out of the box) Pi 3 to a Navio2 HAT. The Pi was powered through the HAT and I verified the proper operation of the WiFi, USB, I2C, and processor/SD hardware.

The Navio2 had an external I2C connector (to a custom-soldered board which I've checked for shorts over and over), UART connector (to a 5V serial radio, where I'm only about 50% sure I got the TX/RX pair right), and of course the power feed.

While everything was working okay, I disconnected the UART and noticed the power LED had dimmed. The Pi also dropped off the WiFi network. Fearing a short was happening, I disconnected everything and then reconnected only power, but the Pi did not reconnect to WiFi.

I connected the Pi to an HDMI display to see what was going wrong; the Pi booted correctly, but upon connecting a USB keyboard I discovered that the USB ports weren't being powered anymore. I tried connecting an Ethernet cable to log in that way, but the Ethernet port was also unpowered (unsurprising as the Ethernet adapter is a USB device). The overheat warning icon also displayed shortly after boot.

I then tried removing the HAT and connected the Pi's UART pins directly to a serial cable, but had no output. I also placed the Pi in the freezer for several minutes just to eliminate the possibility of overheating being the issue. As a final troubleshooting step, I swapped out the Pi3 for a spare and verified all of my troubleshooting to that point (keyboard is powered, Ethernet cable works, UART console, ...) would have worked on an undamaged Pi3.

I don't want to connect any of my spare Pis to the HAT until I have a good hypothesis as to what caused the hardware damage. Unfortunately, the Foundation's published schematics aren't nearly detailed enough to help identify a common circuit, power regulator, etc. that the damaged subsystems use, so my root-cause analysis came to a standstill.

EDIT: Thanks to jdonald's suggestion in the comments, I'm able to get command output despite having no functioning input devices. I'm collecting output for several useful commands here.

  • USB power can be controlled via software, so even if the root cause is a hardware failure, it could induce a crash/hang in a kernel module or system service that leads to other nonresponsive connections even if their respective hardware survived. Can you edit /etc/rc.local on the SD card to fork a command that logs dmesg to a file after bootup? Then see what the earliest "Fail"-like signatures clue into. Surely you'll see at least one error in the log given all the stuff that does even power-on! – jdonald Nov 16 '17 at 1:51
  • You should not need to catch dmesg in rc.local; it's a buffer and will still all be there at login -- in the unusual case in which it has overflowed, it will certainly be in the journald cache. – goldilocks Nov 16 '17 at 2:15
  • @jdonald Thanks for the suggestion! I added a link which includes the dmesg about 60 seconds after boot (plus several other commands I hoped would be helpful). Unfortunately, there doesn't appear to be anything glaringly wrong in dmesg, but journalctl shows some logs from btuart where it fails to reset the Bluetooth controller. – CFSworks Nov 16 '17 at 21:20
  • Nice work obtaining the dmesg and journalctl logs. It's interesting that the internal USB hub manages to enumerate. Perhaps its Vdd line is down but data lines are still intact? If so, you could try through an externally powered USB hub then see if a keyboard or other peripheral enumerates as well. – jdonald Nov 17 '17 at 18:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.