Pi 3 board failure?

It sounds as if there is a problem in your power supply chain.

The first option is ruled out by you trying multiple powersupplies: a bad powersupply.

That, IMHO, leaves only the second one: The fuse on your pi is blown.

The fuse is a "polyfuse" and it is supposed to be self healing. The datasheet says it should be back to its original performance a few minutes after you've shut things down, but stories go around that you may need to wait a day or two. If you want to try "now", put the pi in the fridge for  a few minutes....

That said... The polyfuse is trying to tell you that the pi as a whole is using too much current.... Could it be that one of your peripherals is drawing a lot (too much?) of current? Could you remove all peripherals (do you have an HDMI->VGA adapter? They use power too!) If you need USB peripherals, use a powered hub. Power down the pi, put all peripherals in the hub and make sure they are powered. Then turn on the pi.

Hi Roger,

I did not have any USB devices plugged in when the failure appeared. I've not used any USB device since I received the board. That also would also have been my first thought if I had .

The only peripherals I've ever plugged in are a network cable and the Adafruit serial to USB for the Pi. Both of which work just fine my P 1B. Any screen access I do over tightvnc, everything else I use ssh.

I also suspected the polyfuse so I left the board off for a day figuring that would cool things down sufficiently. No luck on that front I'm afraid.

The symptoms seem strange. The voltage fluctuates between 4.8 and ~3.6 volts when plugged in. Both red and green LEDs flash during the process. The unloaded output of the supply is about 5.1 - 5.2V.

Could this be a tantalum capacitor failing? I note there's a 47u cap at PP7 ( next to D7 on the "schematic") on the board side of the fuse. Whether this is a TA or not is just my speculation.

Thanks for your thoughts.

In my experience, the modern pi's continue to work down to about 3V, provided you don't have anything external connected up that requires 5V (e.g. USB stuff or HDMI converter). Even lower continues to work provided the power is well-buffered with a big capacitor. As far as I know the red light goes off completely if the power is below 4.65V nominal. If it's flashing you're seeing periods above 4.5V too.

Capacitors do act as little batteries, however their capacity is really really small compared to anything you'd normally consider a battery. 47uF  will go from 5V down to 3V (below which your pi crashes anyway), at 0.5A will last almost 200 microseconds. Not something you'll be able to see with your multimeter, registering 3.6V on occasion...

After some further investigation I've done a bit of testing and here's the test and results:

As noted in my original post I was running the Pi3 without incident one day and turned it on the next and it refused to boot.

The symptoms; flashing red LED and flashing green LED for about 20 - 30 seconds then both red and green LEDs go out. Periodically after that the green LED will flash sporadically.

My test.

I suspected something in the 5V input failed so I bypassed the PTC, and MOSFET and applied power to the 5V pins on the header.

The power is from an Adafruit bread board power supply so it is limited to about an amp. I monitor both the 5V rail and a 3.3V pin on the header.

I monitor the console output on the TX pins with a Pi USB serial again from Adafruit.

Results:

With the above arrangement I see a steady red LED and flashing green LED. Both the 5V and 3.3V rails are steady and at the correct voltage.

There is no output on the console so I retried with my network connected and ping just in case there's something wonky with the serial I/O.

Nothing feels hot to the touch on either side of the board.

Note that the boot SD card, serial connector and network connection all work correctly when attached to my Pi1.

I've resigned myself to the fact there's a component failure and I have a $80 brick ( that's the cost CDN for the board + delivery).

Any other ideas would be most appreciated.

When you said 5V on the header, did you mean the GPIO 5V pin?

All of my Pis light their red LEDs for as long as power is supplied. For earlier models when I made a key mistake of using a poor-quality, powered USB hub, that was even the case when the main 5V power was cut, but the USB hub power was still connected (the hub was passing power back to the Pi, which is a real no-no).

The fact that the green light flashes seems to show that something is being booted from the SDHC card and that the regulator is supplying 5V and 3.3v for at least part of the time. Your last test seems to indicate that the switching regulator is working well. I don't know why the red LED is flashing and not staying on, permanently, but the answer may be in the early boot serial output.

I have never investigated the serial output from the early boot stages using the serial port, but my thought is that the moment an HDMI screen is detected, the OS is configured to route the serial output to that screen. The OS does a lot of auto-configuring during the first boot. Cards that boot well on some of my Pis cause a kernel panic on the Pi 3. I don't know what is required to divert the serial stream to the serial port, but I don't think it happens automatically when the monitor is disconnected. That might be the reason you're not seeing anything on the serial port.

I think the blank HDMI monitor is another issue entirely and that needs to be resolved in order to see the serial stream.

Sometimes all the Pis will have problems with HDMI monitors. My Pi 3 booted into low resolution instead of 1080p. Other folk get nothing at all because the Pi is outputting an HDMI signal that the monitor or TV cannot handle. I think you should revert to conventional power and HDMI and make sure that the HDMI monitor will be driven. I'm assuming a PAL 1080p 16:9 HDMI monitor. If you are using something else, you need to check,

RPiconfig - eLinux.org

Here are the lines in my config.txt which force HDMI boost and force PAL 1080p 16:9, HDMI resolution. I don't know if the sdtv settings are actually required, but, if it works...

# uncomment to increase signal to HDMI, if you have interference, blanking, or

# no display

config_hdmi_boost=4

# For 1080p display

sdtv_mode=2

sdtv_aspect=3

hdmi_group=1

hdmi_mode=16

Note: sdtv_mode=0 switches to Normal NTSC.

If you still don't get anything on the monitor, try the following,

# uncomment if you get no picture on HDMI for a default "safe" mode

hdmi_safe=1

# uncomment if hdmi display is not detected and composite is being output

hdmi_force_hotplug=1

I have not found these lines to be helpful, but it depends on the screen.

The early boot screen should give you some view of what is going wrong.

Roy Leith wrote:

All of my Pis light their red LEDs for as long as power is supplied. For earlier models when I made a key mistake of using a poor-quality, powered USB hub, that was even the case when the main 5V power was cut, but the USB hub power was still connected (the hub was passing power back to the Pi, which is a real no-no).

The passing back of power from the hub to the pi is said to be "bad" by a lot of people. But it's not that bad. It can lead to unexpected situations, that you think you make the pi powerless, but it remains running.

Newer pi's have a circuit that is tuned to indicate "4.65V or more". This is then forwarded to the red led. So the red led on means: we have 4.65V or more and no red led means "4.64V or less".

The fact that the green light flashes seems to show that something is being booted from the SDHC card and that the regulator is supplying 5V and 3.3v for at least part of the time. Your last test seems to indicate that the switching regulator is working well. I don't know why the red LED is flashing and not staying on, permanently, but the answer may be in the early boot serial output.

"Flashing" can mean different things.  A regular flash is something entirely different from what we expect, a semi-random on-and-off with periods of "indistiguishable from on" and short periods of "off".

I have never investigated the serial output from the early boot stages using the serial port, but my thought is that the moment an HDMI screen is detected, the OS is configured to route the serial output to that screen. The OS does a lot of auto-configuring during the first boot. Cards that boot well on some of my Pis cause a kernel panic on the Pi 3. I don't know what is required to divert the serial stream to the serial port, but I don't think it happens automatically when the monitor is disconnected. That might be the reason you're not seeing anything on the serial port.

In principle, this is not autodetected, as far as I know. The kernel is normally booted with console=/dev/ttyAMA0 console=/dev/tty0  (or something equivalent on newer pi's.) So the (early) kernel output goes both ways.

Thanks Roger,

My enduring feelings of guilt for using cheap powered USB hubs are assuaged.

I am more convinced than ever that the Pi is working after a fashion.

My suggestion, now, is to revert to standard connections with the changes to the config.txt settings to get HDMI working, but keep monitoring the serial port as well as the HDMI monitor. In addition, monitor the 5V rail closely during boot (which is relatively short) and see if it dips towards the 4.65V figure that Roger supplied. It seems unlikely as you are using a PSU delivering 5.1V or 5.2V. However, a switched mode PSU that has gone on the blink might drop its voltage during the higher current boot phase.

You don't say how you are monitoring the TX port. I use putty on a Linux desktop or a second Pi and, in my experience, USB serial ports do not appear as /dev/tty0 or /dev/tty1 in the Pi, but more likely /dev/ttyusb0. You will have to hunt around for it in /dev (or your chosen computer equivalent) and set up putty to use that device. I noticed the following at RPi Serial Connection - eLinux.org

• Built-in (standard) Serial Port: the Linux standard is /dev/ttyS0, /dev/ttyS1, and so on
• USB Serial Port Adapter: /dev/ttyUSB0, /dev/ttyUSB1, and so on.
  • Some types of USB serial adapter may appear as /dev/ttyACM0

NOTE FOR RASPBERRY PI 3: The Raspberry pi 3 has changed things a bit and you might need to add the option enable_uart=1 at the end of /boot/config.txt.

Speed (baud rate): 115200

• Bits: 8
• Parity: None
• Stop Bits: 1
• Flow Control: None

It would be a good move to make sure it is working with the TX pin of another Pi. There is no reason why the the console device has to be a Pi. It could, just as easily, be a Windows or other Linux computer. Both Windows and Linux support putty.

And finally, if you can bear it, re-image the SDHC card and make the changes to config.txt before booting it.

Hi Roy,

Your questions:

"When you said 5V on the header, did you mean the GPIO 5V pin?"

Yes. I've measured and it appears directly connected to the network on the schematic "5V" which is the protected bus at PP7. See the "Power In" portion of the schematic.

"You don't say how you are monitoring the TX port"

From my response above - "I monitor the console output on the TX pins with a Pi USB serial again from Adafruit."

I connect to this with Putty with the appropriate parameters.

Note from my original post, that this all worked fine when I turned things off. I'd been configuring the system and running for a couple of weeks before this happened.

Also, as noted above, the only connections to the board are an network connector and the serial port cables (TX, RX, gnd, - no power from the USB) , other than power and ground from my bread board power supply of course. As I said originally, all this works fine on my Pi1.

"And finally, if you can bear it, re-image the SDHC card"

I've re-imaged the boot card and tested it on my Pi1 with jessie lite which is the "headless" version. It works just fine there. The Pi3 will boot another image of course but other than that, all else is identical.

Note also that there is no network response to ping as there was when the board was functional.

Kinda frustrating I know, but maybe this is a case of "infant mortality". My Pi1s ( I have two) have been working since I got them several years ago, one of which has run for hours a day without issue.

Thanks for your interest and thoughts.

Hi Sunny,

As I said

The OS does a lot of auto-configuring during the first boot. Cards that boot well on some of my Pis cause a kernel panic on the Pi 3.

The effect of the kernel panic on the Pi 3 is that the red LED comes on and the green LED flashes, but the OS does not complete booting. I propose reflashing, setting up config.txt and only booting on the Pi 3 to avoid mis-configuration. You do not say if you intend to run the Pi 3 in headless mode. If you do, you need to add the option enable_uart=1 at the end of /boot/config.txt in order to see the boot phase in putty and see what is going wrong.

Booting in full fat Raspbian would provide both the console output and the 'Rainbow Square' low voltage warning that may not be properly indicated on a voltmeter (especially a digital one with its sampling delay.

The rainbow-square as an indication for "not enough power" was replaced by a yellow powerbolt in a recent update.