Page 1 of 1

RUN breakout on B+

Posted: Sat Jul 26, 2014 10:18 pm
by domeu
Does anyone know what is the purpose of the RUN breakout (2 pins holes) just next to the leds of B+?

Re: RUN breakout on B+

Posted: Sat Jul 26, 2014 10:20 pm
by mahjongg
reset header.

Re: RUN breakout on B+

Posted: Sun Jul 27, 2014 9:46 am
by domeu
That's really strange to name a "reset" as "Run" !
Did someone already tested it on a B+

Re: RUN breakout on B+

Posted: Sun Jul 27, 2014 10:22 am
by rpdom
domeu wrote:That's really strange to name a "reset" as "Run" !
Because it is connected to the "RUN" pin on the chip, which when held high (via a resistor) lets the chip run. When the link is connected it shorts that pin to ground and clears the RUN state.
Did someone already tested it on a B+
It works for me.

Re: RUN breakout on B+

Posted: Sun Jul 27, 2014 10:50 am
by domeu
@rpdom: thank for the explanation. It is a very valuable response

Re: RUN breakout on B+

Posted: Sun Jul 27, 2014 2:06 pm
by mahjongg
closing the run header resets the PI from a shutdown situation, so it restarts.

Re: RUN breakout on B+

Posted: Wed Sep 10, 2014 2:09 pm
by xjonx
Has anyone experimented with this header? I would be intrested to know if closing and opening these pins will bring the PRi out of the halt state like the P6 header will do on the previous models.

Re: RUN breakout on B+

Posted: Wed Sep 10, 2014 2:38 pm
by RaTTuS
xjonx wrote:Has anyone experimented with this header? I would be intrested to know if closing and opening these pins will bring the PRi out of the halt state like the P6 header will do on the previous models.
yes it is the same

Re: RUN breakout on B+

Posted: Thu Sep 11, 2014 2:32 pm
by xjonx
You're the best! :D

Re: RUN breakout on B+

Posted: Thu Jan 21, 2016 8:00 pm
by nxet
are these pins by any chance readable via software?
my idea is to have the state change to also trigger a shutdown command when the raspi is on. would that be even possible?

Re: RUN breakout on B+

Posted: Fri Jan 22, 2016 8:32 am
by RaTTuS
nxet wrote:are these pins by any chance readable via software?
my idea is to have the state change to also trigger a shutdown command when the raspi is on. would that be even possible?
no it is a direct link to the GPU reset

Re: RUN breakout on B+

Posted: Wed Mar 02, 2016 10:05 am
by UnlikelyBarley
nxet wrote:are these pins by any chance readable via software?
my idea is to have the state change to also trigger a shutdown command when the raspi is on. would that be even possible?
Not using those pins, but using a GPIO pin you can. Something like this:
http://www.instructables.com/id/Simple- ... wn-Button/

Using this you would end up with a button to shutdown the pi to the halt state (power on, but not running), and another button to restart the pi (from any state, including running and halt).

I've not implemented this myself yet, but it is on my list of thing to do for my OctoPi printer host.

Hope this helps.

Re: RUN breakout on B+

Posted: Wed Nov 29, 2017 11:53 am
by Emma_Jir
Has anyone tried tose on a 3B+ Model?
I suppose they are located right under Pin 39 (GND) next to the usb port.
I carefully soldered wires to them but it seems that they response very sensitively. I tried short circuiting them over a kOhm-Resistor but it is not allways effective. It seems they response to static electricity too and i am afraid a cable would maybe even act as antenna scince the device reboots when i move the device in physical area when running. Is there a more proper way to use Run-pins?

Re: RUN breakout on B+

Posted: Thu Nov 30, 2017 6:51 am
by DougieLawson
One of the run pins is just a GND [round pin]. The other [square pin] is the signal which pulls the _RESET_ pin on the processor LOW when you ground it. So the way to avoid spurious resets you need a 10K pullup on the signal pin to 3V3 so that the pin doesn't float and you don't get noise when your long wire acts as an antenna.

Re: RUN breakout on B+

Posted: Thu Nov 30, 2017 1:01 pm
by Emma_Jir
Thank you i forgot about this tri-state-thing. But the location of the pins on model 3b+ is correct (between GPIO-Pins and USB-Ports roughly on the upper right corner)?

Re: RUN breakout on B+

Posted: Thu Nov 30, 2017 1:50 pm
by klricks
Emma_Jir wrote:
Thu Nov 30, 2017 1:01 pm
Thank you i forgot about this tri-state-thing. But the location of the pins on model 3b+ is correct (between GPIO-Pins and USB-Ports roughly on the upper right corner)?
Yes..... look for the RUN silk screen label on the board.
"Tri state" has nothing to do with the RUN pins or any other pins on the RPi......

Re: RUN breakout on B+

Posted: Thu Nov 30, 2017 7:49 pm
by Emma_Jir
klricks wrote:
Thu Nov 30, 2017 1:50 pm
"Tri state" has nothing to do with the RUN pins or any other pins on the RPi......
so the rpi-technology is beyond tri-state?

Re: RUN breakout on B+

Posted: Fri Dec 01, 2017 12:20 am
by rpdom
Emma_Jir wrote:
Thu Nov 30, 2017 7:49 pm
klricks wrote:
Thu Nov 30, 2017 1:50 pm
"Tri state" has nothing to do with the RUN pins or any other pins on the RPi......
so the rpi-technology is beyond tri-state?
Tri-state applies to outputs. The RUN pin is an input.

Re: RUN breakout on B+

Posted: Fri Dec 01, 2017 12:43 am
by klricks
Emma_Jir wrote:
Thu Nov 30, 2017 7:49 pm
....
so the rpi-technology is beyond tri-state?
I am not sure what you mean?
Tri-State is a decades old feature of some chips that allow the outputs to be turned off like a switch: https://en.wikipedia.org/wiki/Three-state_logic
The RUN circuit has no such controls.

Re: RUN breakout on B+

Posted: Fri Dec 01, 2017 3:27 pm
by Emma_Jir
Right, thanks for the rectification i got confused.

The last question would be wich one is input and wich one is gnd on pi model 3B+ i can't make that out.

Re: RUN breakout on B+

Posted: Fri Dec 01, 2017 3:31 pm
by rpdom
Emma_Jir wrote:
Fri Dec 01, 2017 3:27 pm
Right, thanks for the rectification i got confused.

The last question would be wich one is input and wich one is gnd on pi model 3B+ i can't make that out.
If you look carefully at the pads around the holes, one is square and one is round. The round one is the GND side.

Re: RUN breakout on B+

Posted: Thu Aug 30, 2018 2:29 pm
by smbrandonjr
Sorry for commenting on such an old thread but am wondering if it is possible to discern pro grammatically, the difference between a reset performed by utilizing the run header versus a normal shutdown or reboot versus a power loss/power applied.

I want to incorporate a reset switch on my pi that when triggered, runs a script to reconfigure the dhcpcd.conf file to a default setting. I am trying to avoid eating up any GPIO pins as I utilize most of them currently and have ideas for near future that would utilize the remaining.

I am fine with the pi rebooting/shutting down during the reset, as long as there is a way for me to know the reset was triggered by the run trigger versus some other reboot condition.

Mike

Re: RUN breakout on B+

Posted: Thu Aug 30, 2018 3:39 pm
by hippy
smbrandonjr wrote:
Thu Aug 30, 2018 2:29 pm
am wondering if it is possible to discern pro grammatically, the difference between a reset performed by utilizing the run header versus a normal shutdown or reboot versus a power loss/power applied.
Not entirely sure how useful or usable it is or what you will be able to discern between but I would start with investigating -

vcgencmd get_rsts

That however just returns "get_rsts=34" for me after a reboot or a shutdown then power cycle. No access to the RUN header so don't know if that, or power-fail, will set any extra bits.

Re: RUN breakout on B+

Posted: Thu Aug 30, 2018 4:08 pm
by smbrandonjr
but I would start with investigating -

vcgencmd get_rsts
Thanks for pointing me in that direction. Unfortunately I am unable to use that value to discern between a run reset or a power reset during my testing.

Mike

Re: RUN breakout on B+

Posted: Thu Aug 30, 2018 7:31 pm
by hippy
Two options I can think of. First is speculative in that you could create your own bootcode.bin which gets early access to the PM_RSTS register and can stash that away somewhere and then daisy-chain to the real bootcode.bin. But if the ROM bootloader has read and reset PM_RSTS already you'll have nothing to read.

Second, and probably easier, is to use a hardware solution. You might be able to avoid using any GPIO pins if you turn that into a USB device from which you can read whether power was present when reset asserted, and you could probably modify the Pi software so that knows if a safe reboot or shutdown was performed.

One difficulty these days may be the introduction of PMIC chips which may hold the device in reset until power is present. You might need to have a proxy reset button so you can tell if that were pushed or not.