Hardware issue overheating while booting and fail to boot

[DIDquest]

Short version:
A functional RockPro64 stopped working, and fails to boot. Clean Reinstall on SD card completed -- no effect, still cannot boot. If plugged in for more than 3-5 minutes the heatsink on the cpu will become noticeably hot to the touch (implying some sort of operation is being run on the cpu). The LED indicator is no longer coming on (i.e. the one that sits directly behind the reset button).

Longer version:
I originally had a RockPro64 that was functional. One day, after using it for a while (I was testing out vnc viewers), I left for a moment and when I returned the device was powered but the screen had shut off. I attempted to wake it (failed), tried to reboot it (failed), unplugged and waited a bit before plugging it back in, it still failed to boot. I then left it for a few minutes and when I came back, the heatsink on the CPU was hot to the touch (yet the LED indicator located behind the reset button which is usually on when the board is on, was off). I unplugged it to let it cool down. Once cool, I plugged it back in and tried to use both the reset button and the power button in an attempt to force the boot sequence to start. Neither produced any results. The board started to get hot again so I unplugged and decided to check the SD card. It seems to be undamaged (all my files were accessible so I was able to retrieve my files). Returned the SD card to the board and tried to boot again -- same result (overheating with a black screen-- no blinking cursor, nothing, I dont think the screen even recognized the input). I decided to bite the bullet and reburn a clean image of the linux distro onto it and try again. No issues during the burn process and I returned the SD card to the board and attempted to boot it). Exact same result -- no lights, no signals, but if you leave it for 5 minutes the heatsink will be hot. The only indication LED that is still on is the DCIN one.

I have tried different computer monitors, to no effect. I think it is also important to note that when the board was functioning normally, the heatsink would remain cool to the touch during the boot up process and even during light usage (i.e. writing some code). Something very abnormal has occured, and I think it is a hardware issue, but I am kind of stuck at this point.

Any insight into what I should attempt next would be appreciated (or confirmation that someone else as experienced something similar).

[Bullet64]

What output you get on UART?

[dukla2000]

Looks like a death in action. But ...

The heatsink getting warm indicates to me it is alive which is promising. Running warmer than "normal" because no OS has loaded to play withh the governor.


Is the LAN plugged in - are you getting any lights on the RJ45 socket?

Can you try SSH across your network (just to try find signs of life)? Would assume white LED and HDMI are bust which is barely plausible but ...

Have you got eMMC plugged in? (Or anything other than HDMI, keyboard?)

Only straw to clutch at is you have written to the SPI so the boot is looking for bootable USB. Really long shot this and unlikely!! Normally (as you know) white LED behind Reset comes on as OS starts to load, a few seconds after power on. (This reminds me it is possible to jumper some PI2 pins to clear/override this - must find & add to wiki!)

You could try monitor via serial cable (on the assumption you have one).

You could try playing with the Recover button (as per Ayufan - see link from wiki here.)

[dkryder]

maybe erase the spi boot flash because it could have become corrupted

[DIDquest]

Thanks for all the feedback,

Re: Bullet64:
 I don’t have a serial cable on me at the moment (I know I have one, but it is buried in one of my boxes of parts and I will give it a shot once I find it….)

Re: dukla2000:
I plugged in the LAN (it was not attached originally): first when disconnected both green and red lights are ON solidly. When connected to a router the orange is solid and the green flashes intermittently. When connected directly to my laptop the green light is solid while the orange flashes intermittently.
I attempted to SSH into the device when on the LAN, but the connection timed out. (This was the same response I got when I purposefully tried to SSH onto an IP address that I know was reserved but not in use).
No, I do not have an eMMC plugged in. No there is nothing else plugged in (I unplugged the HDMI because it wasn’t working anyway).
I don’t have a serial cable on me at the moment (I know I have one, but it is buried in one of my boxes of parts and I will give it a shot once I find it….)
The link in the Wiki regarding the recover button led to a great little tutorial on using a serial connection to access the board… which I will try once I find that serial console… Unfortunately, it contained no reference to what the recovery button does or extra steps that you will have to do. I have been curious about what that button will do, but without an official explanation (in a manual or something), I have been hesitant to press it. I hope it just resets the default hardware values (like a factory reset), has anyone used it before to verify this?

Re: dkryder:
I can try that after testing the UART serial connection and possibly the recovery button (if I was correct about what it does). Just to check, does the following link provide the correct image for rockpro64 (it seems to be for the Rock64 – I don’t forsee it causing a problem, but it is useful to check first). Also, if someone else comes across a similar problem (and this helps fix the problem) it may help them out.  (  https://github.com/ayufan-rock64/linux-b...ash-spi.md  )

Thanks again for all the feedback!

[dukla2000]

The link in the Wiki regarding the recover button led to a great little tutorial on using a serial connection to access the board… which I will try once I find that serial console… Unfortunately, it contained no reference to what the recovery button does or extra steps that you will have to do. I have been curious about what that button will do, but without an official explanation (in a manual or something), I have been hesitant to press it. I hope it just resets the default hardware values (like a factory reset), has anyone used it before to verify this?

Ooops  

Corrected the wiki - try this now.

It should connect you via OTG to something low level on your board - a bit like flashing firmware on your mobile phone. Havent tried it myself, figure you have little to lose. Especially after 1 blink if you can see the SDcard from the other end of your OTG cable that would be hugely encouraging.

I have updated the wiki about the SPI jumper - again worth a shout IMHO just to eliminate any crud that may have happened to your SPI. (And far more useful than the github flash/erase page you linked: that requires your Rockpro64 to be running and so far we are not sure of that!) But again RJ45 lights give hope it has not stopped breathing yet!

[dukla2000]

Apologies for double post but I have been playing with OTG mode and added a section to the wiki about it here.

Would be interesting if you can get into OTG mode. If so in (mode "1") if you can see anything from your SD card?

[dkryder]

i don't own the pro version so i can't speak to if the same routine is used on the pro as is used on the standard rock64.

[DIDquest]

Re: Bullet64 and dukla2000:
So, I found the serial connection (just to be clear, it is a usb-TTL adapter), and some interesting results were encountered.
First, I followed the the guide from the wiki here (https://forum.pine64.org/showthread.php?tid=6387 ).

When the commands that were listed in the linked wiki article were run the results are shown in images 1 and 2 (attached). To be honest, this seemed to be way too few output lines. Even if I got the baud rate incorrect (which would lead to gibberish like what is seen, or at least somewhat similar), there should be way more lines as the system starts up. Not promising. Just in case, should the Baud rate be 1500000 or another number?

I tested some other common rates (110, 150, 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, 921600, 1000000, 3000000), all of them produced varying amounts of gibberish (if you are interested refer to attached image 7 for an example (there was a max of 5 images per post, so I cut the less interesting ones)

I then tried to enter OTG mode, and it looks like the recovery button and the LEDs work. However, the I don't see anything when connected via a usb (tried it in linux and windows) and according to the wiki "In all cases the USB device made available at the host has device ID 18d1:d00d. " That ID does not appear when I use "lsusb" to search the attached usb devices. (If there is a different command I should be using please let me know)

What is interesting to me was that a couple of times I left the serial connection in place with the terminal still recording. Attached image 3 was the full output from plugging the device in then turning it off via the power button. Image 4 is what happened when I followed the recovery mode 1 procedure (hold down recover button then press and release power button. Release recovery button once LED flashes the desired number of times, in my case 1. Then red light will come on.. all of which happened).  What followed was an unending stream of a single symbol (could it be a blinking cursor or something like that?). Whatever it is, it is being continually output to the serial console.....interesting...(not particularly helpful, but hey it is something).

re: dkryder:
Just in case, I will attempt to erase the spi boot flash as you suggested (as soon as a clean up one of my other sd cards to use during that process), and will update on the results when I have them.

If anyone has any other suggestions please let me know (and thanks for all the help so far).

[Bullet64]

Not every usb-TTL adapter works with 1500000. I have tested three before i found an working adapter.

But i think your board isn't dead. The last image looks good.

1. Erase SPI or set the jumper.
2. Flash an new image to an working sd-card

But the main part is to get an working UART connection. Without it, it's hard to find the problem.