Orange Pi (One) Hardware reset


Recommended Posts

Donate and support the project!

Does anyone know how make hardware reset of the Pi one board?  :wacko:

 

Check schematics: On sheet 6 a Reset Option is described. AFAIK the only H3 board implementing a reset button is Nano Pi M1.

 

BTW: Powercycling any H3 Orange Pi is also somewhat challenging since both USB-UART adapters as well as eg. a PC connected to the Micro USB port will power the board and simply switching DC-IN off and on again after a few seconds does either do nothing or leaves the board in an unpredictable state (very annoying when testing FEL boot a few months ago).

 

Maybe you should ask in linux-sunxi IRC, IIRC a few devs soldered reset buttons/switches to H3 boards but maybe that was A64/Pine64 instead (suffers from the same backpowering troubles)

Link to post
Share on other sites

Yes, the problem is that a simple switching off the power is not quite stable restarts the board.

And the more the problem worsens if the board is powered up with 2 points.

I saw schematic and understand that RESET part is optional, which means physically not wired.

But I can't connect directly to ap-reset point because it is not reachable on that board.

I need stable reset to make external watchdog. But i didn't find the way how.

 

Sorry for my bad english... :(

Link to post
Share on other sites

So you have a device, that comes with zero (0) storage /memory option and you ask "how to reset".

This is funny, right ?

 

Did you think that if the device came with zero storage/memory, that don't need reset? I think it is not right... 

Reset not means erase. Isn't it?

 

I'm sorry if my question was not clear.   :unsure:

Link to post
Share on other sites

I'm sorry if my question was not clear.   :unsure:

 

Your question was absolutely clear -- no worries.

 

I don't know much about electrics so no idea how to add a reset switch on the Oranges. Better go with NanoPi M1 if you really need an easily accessible hardware reset.

 

When I was testing FEL boot (requires a reset after each try) I tested with 2 Orange Pi PC that were connected via DC-IN to a PSU, via Micro USB to my build host FEL booting the Oranges and via serial console to an A20 board. I had to use a powered USB hub between build host and the Oranges since the following was necessary to realibly power-cycle the 2 boards:

  • switching off the 2 sockets of the programmable power switch the PSUs were connected to (see example)
  • switching off the socket where the USB hub's PSU was connected to
  • telling the A20 board to switch off 5V USB voltage for each USB-UART adapter.

Only then an absolute reliable restart was possible (taking 10 seconds). BTW: With our current legacy kernel there exists a software watchdog too: http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=1519&highlight=reset

 

(but when I was testing undervolting H3 boards a few weeks ago I found this to not be reliable -- the daemon writing to /dev/watchdog was still working while the system itself became unstable)

Link to post
Share on other sites

Thanks for your answer! I use watchdog but there are some nuances:

1. The maximum delay time is not longer than 16 sec.;

2. If the device hangs during boot or shutdown (sometimes though not often) that the watchdog will not help....

 

Third-party device could resolve this problem, but there is no hardware reset.  :wacko:

Link to post
Share on other sites

As @zador said, a button in parallel with C301, it means that VCC should be applied to C301, not a short with GND.

Anyway, if a GND is applied on Q9 collector, it is good too.

 

Yes, I understand about button, As I say shutting the capacitor (that means shut to VCC as on scheme) not to GND, is not working...

Link to post
Share on other sites

I was about to open a new thread makig the same question as OP but for the OPI PC. It was nice to find this first.

Fortunately the OPI PC is similar to the One.

 

http://i.imgur.com/Tyrbb5g.jpg

 

I have no idea why technik007_cz and Tido were acting like that. It's very handy to be able to hardware reset the board. I have a raspi running headless 24/7 and an arduino connected to it, pinging it periodically through the GPIO. If for some reason the raspi freezes and stops responding for a while, the arduino resets it.

I intend to do the same with the OPI PC.

Link to post
Share on other sites

Besides the reset button which is manual, Has anyone resolved the watchdog issue solution I get this crash when oprangepi zero is on for a few days. My feeling is that the xradio drivers are messing the kernel up. I am trying to enable watchdog and build a process that resets watch if the kernel/filesystem is healthy. If not than watchdog should reboot orangepi z and start it fresh. 

 

[  456.070016] ------------[ cut here ]------------
[  456.080003] WARNING: at kernel/watchdog.c:255 watchdog_timer_fn+0xf8/0x2a8()
[  456.080003] Watchdog detected hard LOCKUP on cpu 3
[  456.080003] Modules linked in: ir_lirc_codec lirc_dev ir_mce_kbd_decoder ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder sunxi_cir rc_core bnep xt_conntrack iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables x_tables btusb bluetooth bmp085 pcf8591 xradio_wlan g_serial mac80211 btrfs [last unloaded: scsi_wait_scan]
[  456.080003] [<c0016a20>] (unwind_backtrace+0x0/0xe8) from [<c0617a00>] (dump_stack+0x20/0x24)
[  456.080003] [<c0617a00>] (dump_stack+0x20/0x24) from [<c0029750>] (warn_slowpath_common+0x5c/0x74)
[  456.080003] [<c0029750>] (warn_slowpath_common+0x5c/0x74) from [<c00297a8>] (warn_slowpath_fmt+0x40/0x48)
[  456.080003] [<c00297a8>] (warn_slowpath_fmt+0x40/0x48) from [<c00a2e2c>] (watchdog_timer_fn+0xf8/0x2a8)
[  456.080003] [<c00a2e2c>] (watchdog_timer_fn+0xf8/0x2a8) from [<c004deb4>] (__run_hrtimer+0xe4/0x260)
[  456.080003] [<c004deb4>] (__run_hrtimer+0xe4/0x260) from [<c004ea24>] (hrtimer_interrupt+0x14c/0x2a0)
[  456.080003] [<c004ea24>] (hrtimer_interrupt+0x14c/0x2a0) from [<c0014a14>] (arch_timer_handler+0x38/0x48)
[  456.080003] [<c0014a14>] (arch_timer_handler+0x38/0x48) from [<c00a6c80>] (handle_percpu_devid_irq+0xb4/0x180)
[  456.080003] [<c00a6c80>] (handle_percpu_devid_irq+0xb4/0x180) from [<c00a3220>] (generic_handle_irq+0x30/0x40)
[  456.080003] [<c00a3220>] (generic_handle_irq+0x30/0x40) from [<c000ef54>] (handle_IRQ+0x8c/0xbc)
[  456.080003] [<c000ef54>] (handle_IRQ+0x8c/0xbc) from [<c000853c>] (gic_handle_irq+0x4c/0x6c)
[  456.080003] [<c000853c>] (gic_handle_irq+0x4c/0x6c) from [<c000dd20>] (__irq_usr+0x40/0x60)
[  456.080003] Exception stack(0xd71f5fb0 to 0xd71f5ff8)
[  456.080003] 5fa0:                                     b6b633a0 b6b68a20 00000027 0000009c
[  456.080003] 5fc0: 0209cc6c 5d4c9a2d 0000001f 0209cbd0 b6b68a20 be8d0928 5d4c9a2d 0000000d
[  456.080003] 5fe0: 002b0b34 be8d08f8 5d4c9a2d 00051740 000f0030 ffffffff
[  456.080003] ---[ end trace f89dfaaa2af67e81 ]---

Link to post
Share on other sites
Guest
This topic is now closed to further replies.