Fails to boot when powered from GPIO socket

[v8dave]

I have tested the M3 with a Raspberry Pi official power which has 5V at 3A and it works fine. I am running Android on the M3.

I made up a cable for the GPIO with pins 2 and 4 for +5V and pins 6 and 9 for GND.

When I power this up from a bench power supply (Rigol DP832A) with this is set for 5.0V at 3A, it draws approx 1000mA, the fan starts and the RED power LED comes on and the BLUE LED flashes for a few seconds. On the S430 LCD I see the initial boot logo and then the BLUE LED goes off and the fan stops.

If I boot with the MicroUSB connected and the power supply also on, it boots as normal. If I unplug the USB the device immediately shuts off.

If I disconnect the GPIO power and then use the Rasperrry Pi Supply via the USB port it works. I need the USB port free to be able to debug the Android app.

The follow appears on the UART output.

Code: Select all

[    5.520000] adb_open
[    5.520000] mtp_bind_config
[    5.520000] adb_bind_config
shell@nanopi3:/ $ [    5.924000] logd.auditd: start
[    6.432000] healthd: No charger supplies found
[    6.432000] healthd: No battery devices found
[    6.628000] ov5640_link_setup
[    6.632000] camera_common_vin_setup_io
[    6.632000] ov5640 0-003c: reg_write: i2c write error, reg: 3103
[    6.636000] ov5640_init: failed to ov5640_write_array init regs
[    6.644000] ov5640_s_power.............1944...........
[    6.648000] nxp_hdmi_link_setup: connected to me!!!
[    7.380000] usb 1-1: USB disconnect, device number 2
[    7.684000] usb 1-1: new high-speed USB device number 3 using nxp-ehci
[    7.816000] usb 1-1: New USB device found, idVendor=05e3, idProduct=0610
[    7.816000] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0

[    7.824000] usb 1-1: Product: USB2.0 Hub
[    7.828000] hub 1-1:1.0: USB hub found
[    7.832000] hub 1-1:1.0: 4 ports detected
[    7.976000] dw_mmc dw_mmc.0: Timeout waiting for hardware interrupt
[    7.976000] cmd18, state: 5, status: 00009106, rintsts: 00000030
[    7.980000] mmcblk0: error -110 sending status command, retrying
[    7.988000] mmcblk0: error -110 sending status command, retrying
[    7.992000] mmcblk0: error -110 sending status command, aborting
[    8.000000] end_request: I/O error, dev mmcblk0, sector 439584
[    8.004000] end_request: I/O error, dev mmcblk0, sector 439592
[    8.012000] end_request: I/O error, dev mmcblk0, sector 439600
[    8.016000] end_request: I/O error, dev mmcblk0, sector 439608
[    8.020000] end_request: I/O error, dev mmcblk0, sector 439616
[    8.028000] end_request: I/O error, dev mmcblk0, sector 439624
[    8.032000] end_request: I/O error, dev mmcblk0, sector 439632
[    8.040000] end_request: I/O error, dev mmcblk0, sector 439640
[    8.044000] end_request: I/O error, dev mmcblk0, sector 439648
[    8.052000] end_request: I/O error, dev mmcblk0, sector 439656
[    8.056000] end_request: I/O error, dev mmcblk0, sector 439664
[    8.064000] end_request: I/O error, dev mmcblk0, sector 439672
[    8.068000] end_request: I/O error, dev mmcblk0, sector 439680
[    8.076000] end_request: I/O error, dev mmcblk0, sector 439688
[    8.080000] end_request: I/O error, dev mmcblk0, sector 439696
[    8.084000] end_request: I/O error, dev mmcblk0, sector 439704
[    8.092000] end_request: I/O error, dev mmcblk0, sector 439712
[    8.096000] end_request: I/O error, dev mmcblk0, sector 439720
[    8.104000] end_request: I/O error, dev mmcblk0, sector 439728
[    8.108000] end_request: I/O error, dev mmcblk0, sector 439736
[    8.116000] end_request: I/O error, dev mmcblk0, sector 439744
[    8.120000] end_request: I/O error, dev mmcblk0, sector 439752
[    8.128000] end_request: I/O error, dev mmcblk0, sector 439760
[    8.132000] end_request: I/O error, dev mmcblk0, sector 439768
[    8.140000] en

[davef]

Just a few suggestions, as I had a lot of trouble firing up a Raspberry Pi 3 on my own power supply creations. Current is one thing, how will filtered and how the supply reacts to surge requirements are probably quite important as well.

Have you got a oscilloscope that you can capture the voltage dips during the boot process? Is the Rigol a linear power supply? Maybe an extra 1000-2000uFd electro to supply any short pulses of current mounted near the board might help.

You are aware that you may have no over-voltage protection feeding power into the GPIO pins. I haven't checked the schematic of your device.

Your error messages ... do you get the same messages each time? There were some issues with the early NanoPi2s that required a rootwait in bootargs to get around issues with the SD cards taking some time to setup.

[davef]

You are aware that you may have no over-voltage protection feeding power into the GPIO pins. I haven't checked the schematic of your device.

A series fuse followed by a 5V6 1 to 5 Watt Zener then to the target would offer some protection.

[v8dave]

This is just initial testing. The design will have a daughter board with a 5V 3A supply so no possibility to get it wired up wrong

The Rigol supply is a programmable linear type and well capable of handling surges. In fact I can record these with the supply so I will set this up and see what it looks like.

Thinking about the dips in the supply in your comment, it could actually be the cable I am using from the PSU to the board. It came off an old failed power supply and has a 5-2.1mm connector. I will make up a new one with 16/02 cable and see if that improves things.

[v8dave]

This is really strange. Looking though the schematic there is no reason that the 5V input on the GPIO should not be able to power the board.

Pins 2 and 4 are connected to VDD_5V which is connected to the AXP228 input.

When you power from USB, mosfet Q1 is switched on and power is connected to VDD_5V. With the USB disconnected and 5V applied to GPIO pins 2 and 4, Q1 is off so the 5V is blocked from reaching the USB socket but this should now be able to startup the board but it fails to do so.

With Debian as the OS there is not an issue to power from the USB port as it does not use the USB for anything. With Android you need this USB port to debug the application over ADB.

I can power the board from the GPIO pins if I have the USB connected at the same time but as soon as you unplug the USB it just powers off.

VBUS is not connected to the AXP228 but it is connected to the processor.

It also fails to boot Debian with power via the GPIO so is not an OS issue as far as I can tell. There doesn't appear to be any indication in the UART output during the boot sequence. This is the last few lines with Debian bootup.

Code: Select all

[   37.852000] Loading modules backported from Linux version v4.4.2-0-g1cb8570
[   37.852000] Backport generated by backports.git v4.4.2-1-0-gbec4037
[   37.912000] systemd[1]: Started Increase datagram queue length.
[   37.968000] systemd[1]: Started Create list of required static device nodes for the current kernel.
[   38.028000] systemd[1]: Started Nameserver information manager.
[   38.076000] systemd[1]: Starting Create Static Device Nodes in /dev...
[   38.084000] systemd[1]: Starting Syslog Socket.
[   38.088000] systemd[1]: Listening on Syslog Socket.
[   38.092000] systemd[1]: Starting Journal Service...
[   38.100000] systemd[1]: Started Journal Service.
[   38.296000] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[   38.304000] systemd-udevd[242]: starting version 215
[   38.304000] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[   38.308000] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[   38.308000] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[   38.392000] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[   38.404000] mmc1: new high speed SDIO card at address 0001

In fact the point that it shuts down is not the same each time.

The Wiki for the M3 indicates that the GPIO can be used to power the board with 4.7 to 5.6V input range. I've tested up to 5.2V.

I need to get this working or the board will not be used for this project. Be a shame as it works really well when powered from the USB port and has been stable for days at a time.

[davef]

I compared the NanoPi schematic to your board. For the NanoPi VDD_BUS_5V only goes from the microUSB connector to the supply switching circuit you describe.

If it was my unit I would try pulling VBUS_5V up to say 3 to 4V. Maybe a suitable divider chain off your 5V that you put on the GPIO pins. Hopefully, that way the processor thinks it has power.

Say 4K7 in series and a 10K to ground.

Remember I said, "if it was my unit"!

[v8dave]

Thanks davef,

I hooked up the scope to the board itself via the UART connector to monitor the VDD_5V line and sure enough it was dropping to around 4.0V. I checked the cable I was using and it seemed to be OK. I've used this for other projects before without issue but mostly just up to 1.5A at 5V.

I swapped out for a larger cable so that there would be less voltage drop and sure enough, it now powers up and during the boot is around 1.8A so the thin cable was not able to supply enough current.

On the final design the cable run from the board and the supply will be mere cms. but I will ensure that I use a polygon to make sure it can take the load.

Cheers for taking a look and giving some pointers.