RUN breakout on B+

[domeu]

Does anyone know what is the purpose of the RUN breakout (2 pins holes) just next to the leds of B+?

[mahjongg]

reset header.

[domeu]

That's really strange to name a "reset" as "Run" !
Did someone already tested it on a B+

[rpdom]

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.

[domeu]

@rpdom: thank for the explanation. It is a very valuable response

[mahjongg]

closing the run header resets the PI from a shutdown situation, so it restarts.

[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.

[RaTTuS]

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

[xjonx]

You're the best!

[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?

[RaTTuS]

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

[UnlikelyBarley]

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.

[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?

[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.

[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)?

[klricks]

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......

[Emma_Jir]

"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?

[rpdom]

"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.

[klricks]

....
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.

[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.

[rpdom]

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.

[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

[hippy]

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.

[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

[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.