rockpro 64 does not boot up automatically after software reboot

[rahulsharma]

Hi, I am using rockpro64 with Ubuntu18.04 LXDE image.
I made a project on rockpro64 that runs continously 24x7. 
Sometimes when light goes or i do software restart, it does not reboot. I have to plug out the power jack and plug it again. SOmetime it reboots automatically after restart.
 Is this common issue? Is it related to Hardware or Image? Any idea?
Thanks.

[hexxx]

Have the same issue with dietpi and libreelec. The board is a piece of shit

[Nikolay_Po]

Hi, I am using rockpro64 with Ubuntu18.04 LXDE image.
I made a project on rockpro64 that runs continously 24x7. 
Sometimes when light goes or i do software restart, it does not reboot. I have to plug out the power jack and plug it again. SOmetime it reboots automatically after restart.

Have you tried to attach RTC backup battery? The ability to restart after power loss is solely depends on RK808 power management controller. If it will be equipped by a backup power source at RTC connector, the restart may become more predictable.

I still don't know why the RK808 may not restart without of RTC battery. System voltage ramps up quite sharp and RK808 should detect the turning on reliable.
How much time the board remained without of power before re-applying? May be power supply networks or the capacitors on ROCKpro64 board was not discharged enough?

[rahulsharma]

Hi @Nikolay_Po , 
Thanks for concern.


Yes the power cut is unpredictable. It ranges from 1 hr to 1 day.
I also think that sudden power on/off make OS corruption. As after few days, the board does not even boot up.

Weirdly when i press power button, then it starts booting.

Also when i reflash the same OS , again it starts working well (auto restart) for few days.

So not able to decide if it is hardware error or OS error.

[Nikolay_Po]

So not able to decide if it is hardware error or OS error.

Rahul, you still didn't said have you tried to connect an RTC battery?

[rahulsharma]

So not able to decide if it is hardware error or OS error.

Rahul, you still didn't said have you tried to connect an RTC battery?

Hi,
No i didn't use any RTC battery. 
I think this will be just for system clock purpose. Thus it will not be used as power bacup for the whole rockpro.
I am talking about the main power fluctuation. 

Let me clarify on my points above-
Requirement-
Device is needed to be used for 24x7 working for on eof my project.

Issue -
Device stops working after few days of working.

Environmental condition-
Power(12V 5A) is getting from SMPS but sometimes main power goes and comes so power shutdown is there unexpectedly and suddenly. And its frequency is not same such as 1-5 times in a day.

Observtions-
Devices were not booting.

Debugging steps-
Few devices work again after reflashing of same Ubuntu18.04 LXDE image .
Few devices boot but with Android OS not with Linux OS.
Few devices even does not boot at all.

So i was predicting if it happened just because of power or image is no stable or something else. Still not able to find main root cause

Note-
I was also thinking for a module or circuit so that can be used for few mins to graceful shutdown to device when main 12V dc power goes.

Thanks.

[Nikolay_Po]

Thank you for explanation. Do you use the same type flash memory in every case? May be the root of the problem is in flash media stability?
I used single ROCKpro64 for several month without a UPS. And after tens of sudden shutdowns there was none startup failures. Both "Transcend microSDXC 300S Class 10 Uhs-i U3 A1 V30 128GB" card and 16GB Pine64 flash module was able to restart correctly after any shutdowns, including power failures.

1. What storage media are connected to your boards at the moment of power failure and restart?
   
2. Was there any Android OS written to the media before? How could it start?
   
3. Was Android overwritten by different OS before failure?
   

The startup of different OS is an interesting fact. If unwanted OS was not kept on the media intentionally it's start may be an evidence of major flash memory controller failure.
It is well known that newer data are always written to the blocks of flash cells which was worn less. So until the amount of data written is less than media capacity the elder information will still persist on the media.
In case of sudden power failure the flash controller may corrupt the data written last. But previously written data, even being overwritten, may return because of controller database intrinsic backup restoration.

Try to perform periodic "fstrim -a". The trimming itself may initiate flash media controller database update. And in case of sudden power loss it may return to more fresh backup than without of trimming.

[rahulsharma]

Thank you for explanation. Do you use the same type flash memory in every case? May be the root of the problem is in flash media stability?
I used single ROCKpro64 for several month without a UPS. And after tens of sudden shutdowns there was none startup failures. Both "Transcend microSDXC 300S Class 10 Uhs-i U3 A1 V30 128GB" card and 16GB Pine64 flash module was able to restart correctly after any shutdowns, including power failures.

1. What storage media are connected to your boards at the moment of power failure and restart?
   
2. Was there any Android OS written to the media before? How could it start?
   
3. Was Android overwritten by different OS before failure?
   

The startup of different OS is an interesting fact. If unwanted OS was not kept on the media intentionally it's start may be an evidence of major flash memory controller failure.
It is well known that newer data are always written to the blocks of flash cells which was worn less. So until the amount of data written is less than media capacity the elder information will still persist on the media.
In case of sudden power failure the flash controller may corrupt the data written last. But previously written data, even being overwritten, may return because of controller database intrinsic backup restoration.

Try to perform periodic "fstrim -a". The trimming itself may initiate flash media controller database update. And in case of sudden power loss it may return to more fresh backup than without of trimming.

Hi, 
Thanks for the elaboration. It gave me some clarifications.

For your querries -
Do you use the same type flash memory in every case?
Yes

What storage media are connected to your boards at the moment of power failure and restart?
eMMC 16GB from pine iteself (FORESEE NCEMAM8B-16G Z1S18061467571826).

Was there any Android OS written to the media before? How could it start?
No only Ubuntu18.04 LXDE image have been used from initial. I asked the same issue with pine support guys they suggested me to test the same with Android 7.2 OS. And it booted don't know how.

Was Android overwritten by different OS before failure?
No, Android was not even in the picture before.

One more point, i tested the same board with Armbian image and it also worked but not with the Ubuntu based eMMC. The interesting point is if i reflashed the same eMMC with fresh Ubuntu image then it works. So clearly OS corruption but few devices even don't boot with any of the OS/new eMMC.

This is still suspicious error for me and i am keep on digging around.

[Nikolay_Po]

You may try to connect TTL_UART-to-USB converter to SBC UART Tx pin, it is transmitting at 1500000 Bauds and connect this converter to a notebook (or to a PC with uninterruptible supply). May be you will got some shutdown or boot messages at the moment of power loss and restart. The hardware UART Tx pin is working right from a Rockchip bootloader start, even without of a media. May be you will got some clue what is wrong.
Another cause of boot failure may be an electromagnetic interference. Particularly if your boards are connected to something else except a power supply by a long wires. Can you reproduce boot failure on your table where nothing else except eMMC flash and UART-USB converter is connected to the SBC?

[rahulsharma]

You may try to connect TTL_UART-to-USB converter to SBC UART Tx pin, it is transmitting at 1500000 Bauds and connect this converter to a notebook (or to a PC with uninterruptible supply). May be you will got some shutdown or boot messages at the moment of power loss and restart. The hardware UART Tx pin is working right from a Rockchip bootloader start, even without of a media. May be you will got some clue what is wrong.
Another cause of boot failure may be an electromagnetic interference. Particularly if your boards are connected to something else except a power supply by a long wires. Can you reproduce boot failure on your table where nothing else except eMMC flash and UART-USB converter is connected to the SBC?

Yes i tried SBC UART with my laptop. I got following observations-
1) Device after got OS curroption, gave me nothing in console even i tried power button press.
2) Same Device after reflash gave me decent Console out and device worked too.
3) Some device which are not booting at all were producing error of "Cap error" in Console that indicates some capacitor go damaged and caused Hardware damage.

I am trying to reproduce the same issue here in my workspace and it has been around 20 days but not able to reproduce same.
Will also try your point of Electromagnetic interferene here. 
Some more people are saying that they got same issue with eMMC. So may be i should continue with good quality SD Card for my future projects.