I’m currently working on a project that involves the PiJuice and one of the things I need the board to do is to wake up or reset the Raspberry Pi under certain conditions. Now the PiJuice can do this in a couple of ways.
For as much as I hate those that will go on and on with fancy music and lengthy intros on their YouTube channel videos about how they stumbled onto something without really getting to the point quick enough, this post actually needs a bit of a preface.
- Remove and reapply the power to the Raspberry Pi
- Reset the Raspberry Pi therefore allowing the OS to reboot.
Assuming the Pi was shutdown via software under normal circumstances it will power off the OS but until you remove the micro USB from the board the circuitry will continue to run.
When Ms-DOS was a thing if you wanted to reset your PC you could either press the Reset button on the case or hold down CTRL, ALT and DEL on your keyboard. Both ways would end up talking you back to your blinking cursor after running your latest incarnation of AUTOEXEC.BAT and CONFIG.SYS. Gosh has it really been that long ago?
Anyways, one method was the hardware reset, the other the software reset and for the majority they didn’t make much difference for your day to day. It turns out that there are two very similar mechanisms for the Raspberry Pi too, let’s see what they are and how can they be triggered.
RUN Pad
The RUN pad allows you to reset the CPU and you achieve that by shorting the RUN pin to ground (Pin 1 with 2)
Often this method has been and still is described as a way of allowing the user to “restart” the Raspberry Pi when other methods wouldn’t work and in case you felt removing the power cord wasn’t “elegant” enough. This method more interestingly allows some add-on boards to add a power management capability to the Raspberry Pi as it is the case for the PiJuice and for PaPiRus.
Without needing to install a header to the RUN pad these boards come with a pogo pin that you can solder on the HAT or pHAT and that, being spring loaded, will provide sufficient electrical contact with pin 1 of the RUN pad. The trace connected to the pogo pin runs to a microcontroller’s pin which will be brought to a logic low to initiate the reset.
Despite generally the A and the B always had the RUN pad in the same place as the A+,B+ became 2B, 3B and eventually 3A+ and 3B+ the position was moved each time and the Zero has always had it’s own location. As you can also see from the pictures the RUN pad has moved quite a lot on the PCB from the early versions of Raspberry Pi through to various A, B and Zero layouts and that meant adding more and more positions on the PCB design of the likes of PiJuice to accommodate depending on which Raspberry Pi you were going to use. Have a look at this “family” photo to get the full … picture
One design consideration could be to abandon support for some of the older models thereby rendering the add-on board layout less crowded, after all there aren’t many reasons for which your project has to run on a B+ and “investing” in a new Raspberry Pi doesn’t cost that much after all but I respect the efforts of backward compatibility and in any case how do you account for future Raspberry Pis?
Safe mode
To the rescue comes an alternative mechanism which has been there since the early days. Safe mode was a way to recover from a misconfiguration on the cmdline.txt whether is was to do with a bad overclocking a wrong display mode or a type in the file contents by invoking this method you would be able to default to a “Safe mode” that would allow you to access the OS once again.
This involved having a safe partition on the SD card something that has been reutilised with Noobs but not with other distributions. There is even who redeveloped his own approach renamed as Raspberry Pi Flipflop.
Despite the Safe mode partition is no longer available for the majority of OSs including Raspbian
EDIT: This feature is removed from default firmware as of 18th March 2014. NOOBS still supports a safe mode, using the same gpio pins.
eLinux
the functionality that triggered a reset is still there and involves shorting pin 5 and 6 (physical notation) on the GPIO header. Essentially taking pin 5 (BCM 3) to ground. Have a look at the good pinout.xyz for more details about the GPIO header.
-Added alternative wakeup via Rpi SCL (GPIO3) if run pin is not connected via pogo pin.
The big advantages of this approach is that pin 5 and 6 have been there with that same function since the early 26 pin header Raspberry Pis and given that Noobs still uses it to this day it would seem safe to think that future Pis (although the future is mysterious with these things) will continue to implement the same exact mechanism.
With regards to the PiJuice, from which all this discussion started from, the new firmware (in Beta at the time of writing this article) will leverage on this very mechanism as a new way of waking up and resetting the Pi. That is of course in case the Pi has been shutdown with a poweroff or a halt command and the power hasn’t completely been removed.
Once again the microcontroller on board the PiJuice will be able to tell whether the pogo pin is installed or not and if it it isn’t it will bring pin 5 on the Pi to a low state achieving the same as placing a jumper between pin 5 and 6.
Which is best then
I had a quick Twitter exchange with Pete Lomas and Ton van Overbeek about these two methods, their origins and purpose. I must admit it has been quite an interesting research on my side.
The Pins 5/6 method is firmware monitored so it cannot be used to wake up the processor or shut it down. People that would choose the RUN Pad method do that because it kills the processor and temporarily removes the current. If you routed power through the HAT there is nominally no reason to use the RUN Pad effectively.
Truth to be said there aren’t many HATs or add-on boards which makes use of the RUN Pad or the Safe Mode at least that I know of but adding power management to the Raspberry Pi is a very interesting feature and quite needed if you want to run on batteries especially in the era of IoT and LoRa.
The RUN Pad can reset the hardware at any moment where the Safe Mode only works when the Raspberry Pi has been shutdown via a halt command. If you really need to reset for example from a hanged Pi the “hard” reset is the only way unless you can somehow pull the plug manually.
Both mechanisms achieve pretty much the same results although quite clearly in terms of design for your next Raspberry Pi HAT the “soft” reset is a big advantage towards the ever moving RUN Pad and I believe that to be the best approach in the end.