5 dead BPI-M3 after one year of inactivity

Dear All,

some years ago ( maybe almost 3 years ) I bought 5 Banana-Pi M3. They were running successfully all over the time. A little bit more than a year ago I replaced these M3 by M64 based on the fact that M64 is a little bit more powerful than M3. I shutdown the M3 and put them into a box. Yesterday I tried to boot one and I had to realize that all 5 of them are dead.

I did everything what came in my mind. I replaced the USB power supply, I replaced the cable. I wrote the SD card with a new image, I took also the old image, I wrote to a brand new SD card. Also tried the USB OTG plug for power instead the power jack I used always. But no way to bring it up.

It always the same. When I power on all 3 LEDs are going on. First the red, than the other two. On the serial console I can watch the boot process. And after about 4.5 seconds the LEDs are dark, the the console hangs. It’s not always at the same boot step. See below. Measuring the current it shows 0 mA power consumption. So it switched off itself. Only unplug/plug from/to power will repeat the boot process until it hangs again. When I hit the return key to stop autoboot I get a prompt and this stays forever.

In my opinion some electronic parts died during this time of inactivity. I also tried to keep it powered on over night. From the old days I know that this big fat condensators died if not used over years. But obviously something similar happened to the M3.

Any ideas what I can do ? Maybe some diagnostics at the boot prompt ? Or did someone else have a similar issue ? I am quite sure if I would run the M3 all the time it would still work.

Kind regards Hans

    [    4.480048] [mmc]: sdc2 set ios: clk 400000Hz bm PP pm ON vdd 3.3V width 1 timing LEGACY(SDR12) dt B
    [    4.495953] ------------audio_hmic_irq----------[mmc]: *** sunxi_mci_dump_errinfo(L824): smc 2 err, cmd 52,  RTO !!
    [    4.501678] [mmc]: *** sunxi_mci_dump_errinfo(L824): smc 2 err, cmd 52,  RTO !!
    [    4.501705] [mmc]: sdc2 set ios: clk 400000Hz bm PP pm ON vdd 3.3V width 1 timing LEGACY(SDR12) dt B
1 Like

Hello, I don’t own a M3 but AFAIK, If you can are getting to the boot screen using UART and reaching the uboot cmd interface there seem to be no problem with the Hardware.

Can you type printenv in uboot command and share the log. Maybe someone with M3 and M3 uboot knowledge can help you with it.

Also have you tried updating the official firmware to the last one from this Link? I assume it must be old firmware with new OS config, as a lot have changed in the uboot.

Hello spikerguy,

many thanks coming back to my posting. Below the result of “printenv”. And yes, we tried an image from this link you provided.

I am not sure if a working uboot prompt is really indicating there is no hardware issue. Maybe the boot process of OS is trying to initialize some i/o which wasn’t needed till now.

Kind regards Hans




boot_normal=if run checkemmc; then setenv partition 2; fi; if run loadbootenv; then echo Loaded environment from ${bootenv}; env import -t ${scriptaddr} ${filesize}; fi; if test -n "${uenvcmd}"; then echo Running uenvcmd ...; run uenvcmd; fi; sunxi_flash read 40007800 boot;boota 40007800 boot;

boot_recovery=sunxi_flash read 40007800 recovery;boota 40007800 recovery

bootcmd=run setargs_mmc boot_normal





checkemmc=fatinfo $device 2











loadbootenv=fatload $device $partition $scriptaddr ${bpi}/${board}/${service}/${bootenv} || fatload $device $partition $scriptaddr ${bootenv}


mmc_root=/dev/mmcblk0p2 rootwait










setargs_mmc=setenv bootargs enforcing=${enforcing} console=${console} console=${fb_console} root=${mmc_root} init=${init} vmalloc=384M ion_cma_list="120m,176m,512m" loglevel=${loglevel} partitions=${partitions} bootmenutimeout=10 datadev=mmcblk1p2

setargs_nand=setenv bootargs enforcing=${enforcing} console=${console} console=${fb_console} root=${nand_root} init=${init} vmalloc=384M ion_cma_list="120m,176m,512m" loglevel=${loglevel} partitions=${partitions}






Environment size: 1775/131068 bytes
1 Like

Yes you’re right. I think someone from the BPI team should look into the log and help you with it.

1 Like