Default GPIO PIN state after boot

[Artyom]

PROBLEM: Random pin state (or pin ON) after boot.
can anyone tell how to define the state of pins after boot?

---

After booting my Rasp PI 2 all GPIO pins are off. After booting Pine64 GPIO pins have random state. Is anyone can help to set GPIO pin to off during the boot process?

---

This is a very serious problem. For example if you use a relay to control the lighting it's not very scary, but if connected leading pump? It will deflate all of the water and burn in case of failure when starting the main control program.

[MarkHaysHarris777]

Actually , the default state of the gpio pins on the Raspberry PI are 'input' , which is 'correct' logic.

The pine board is not consistent in this regard. It may be possible to set the default state in dts|dtb , but I have not looked into it yet seriously; although , I am not at all hopeful.

If you choose your pins carefully , and provide secondary buffering , you can work around the problem.

[Artyom]

Actually , the default state of the gpio pins on the Raspberry PI are 'input' , which is 'correct' logic.

The pine board is not consistent in this regard. It may be possible to set the default state in dts|dtb , but I have not looked into it yet seriously;  although , I am not at all hopeful.

If you choose your pins carefully , and provide secondary buffering , you can work around the problem.

Good evening. You certainly are right, but I'm not looking for a solution to the problem only for me. I wish to attract the attention of the community to solve the problem for everyone.

[MarkHaysHarris777]

Actually , the default state of the gpio pins on the Raspberry PI are 'input' , which is 'correct' logic.

The pine board is not consistent in this regard. It may be possible to set the default state in dts|dtb , but I have not looked into it yet seriously;  although , I am not at all hopeful.

If you choose your pins carefully , and provide secondary buffering , you can work around the problem.

Good evening. You certainly are right, but I'm not looking for a solution to the problem only for me. I wish to attract the attention of the community to solve the problem for everyone.

(emphasis mine)  Yes, I understand that; and thank you.

This is one of those little details that needs to be taken into account for the next generation of pine board;  whatever that may be. 

In short,  as a requirement,  all gpio pins 'must' conform to logical 'inputs' throughout the power-up boot cycle.  

It should be noted that in some use cases the pine board is useless as a controller unless the previous requirement is met. 

Thanks again for your input, I agree whole heartedly.

[Artyom]

Thank you for your kind words. But I still need help in this matter. Technically possible to accomplish this task on the current generation of the board? Can anyone suggest? I'm new to the internet of things and programming.

[pfeerick]

Thank you for your kind words. But I still need help in this matter. Technically possible to accomplish this task on the current generation of the board? Can anyone suggest? I'm new to the internet of things and programming.

As Marcus said, the pine64 board is not reliable or robust enough on that front at this point in time. It could be as simple as changes needing to be made to the device tree settings, or it could be a issue that we can't work around until the OS has fully loaded. If your goal is reliability, it is probably better to use the serial or I2C bus to talk to another microcontroller like a Arduino or PIC, which does have reliable power-on states.

Marcus: What do you think of external pull downs (say 10K) with a 74HC7014 (hex non-inverting Schmitt-trigger) - do you think that would buffer the output enough? Are there any particular pins that are more random/noisy than others during bootup?

[Artyom]

Thank you for your kind words. But I still need help in this matter. Technically possible to accomplish this task on the current generation of the board? Can anyone suggest? I'm new to the internet of things and programming.

As Marcus said, the pine64 board is not reliable or robust enough on that front at this point in time. It could be as simple as changes needing to be made to the device tree settings, or it could be a issue that we can't work around until the OS has fully loaded. If your goal is reliability, it is probably better to use the serial or I2C bus to talk to another microcontroller like a Arduino or PIC, which does have reliable power-on states.

Marcus: What do you think of external pull downs (say 10K) with a 74HC7014 (hex non-inverting Schmitt-trigger) - do you think that would buffer the output enough? Are there any particular pins that are more random/noisy than others during bootup?

It should at least make sure that the majority (or all, if possible) gpio pins were off (logic zero) immediately after the operating system is loaded. You can certainly make them like raspberri PI.

[MarkHaysHarris777]

Thank you for your kind words. But I still need help in this matter. Technically possible to accomplish this task on the current generation of the board? Can anyone suggest? I'm new to the internet of things and programming.

As Marcus said, the pine64 board is not reliable or robust enough on that front at this point in time. It could be as simple as changes needing to be made to the device tree settings, or it could be a issue that we can't work around until the OS has fully loaded. If your goal is reliability, it is probably better to use the serial or I2C bus to talk to another microcontroller like a Arduino or PIC, which does have reliable power-on states.

Marcus: What do you think of external pull downs (say 10K) with a 74HC7014 (hex non-inverting Schmitt-trigger) - do you think that would buffer the output enough? Are there any particular pins that are more random/noisy than others during bootup?

It should at least make sure that the majority (or all, if possible) gpio pins were off (logic zero) immediately after the operating system is loaded. You can certainly make them like raspberri PI.

Well, again, the Raspberry PI defaults to "inputs" on all gpio pins;  this is hugely different than defaulting to "off".  The fact that the pins can be "input" with either pull-up or pull-down internal resistors;  the pin can be technically HIGH or LOW and still be an input state!

The problem that we have when developing control ciruits is knowing what happens during POR (power on reset) and what happens during abnormal power-down.  Personally, I don't feel like *any* control SBC at the moment has the reliability to be trusted in a single level installation;  although, some are notably better than others ( the Raspberry PI is better than the Pine in this regard ).

POR must be controlled in 'stages' and the entire system must be protected against accidental power-off. This is obviously going to be more than a signle level control board attached to relays. Multiple level control and redundancy are required, and final power control is required. Things would be a lot easier if SBC(s) could be made reliable enough that ALL gpio pins would remain in the input state ( pullup or pulldown ) throughout the POR --- but, its not there yet.

[Artyom]

Thank you for your kind words. But I still need help in this matter. Technically possible to accomplish this task on the current generation of the board? Can anyone suggest? I'm new to the internet of things and programming.

As Marcus said, the pine64 board is not reliable or robust enough on that front at this point in time. It could be as simple as changes needing to be made to the device tree settings, or it could be a issue that we can't work around until the OS has fully loaded. If your goal is reliability, it is probably better to use the serial or I2C bus to talk to another microcontroller like a Arduino or PIC, which does have reliable power-on states.

Marcus: What do you think of external pull downs (say 10K) with a 74HC7014 (hex non-inverting Schmitt-trigger) - do you think that would buffer the output enough? Are there any particular pins that are more random/noisy than others during bootup?

It should at least make sure that the majority (or all, if possible) gpio pins were off (logic zero) immediately after the operating system is loaded. You can certainly make them like raspberri PI.

Well, again, the Raspberry PI defaults to "inputs" on all gpio pins;  this is hugely different than defaulting to "off".  The fact that the pins can be "input" with either pull-up or pull-down internal resistors;  the pin can be technically HIGH or LOW and still be an input state!

The problem that we have when developing control ciruits is knowing what happens during POR (power on reset) and what happens during abnormal power-down.  Personally, I don't feel like *any* control SBC at the moment has the reliability to be trusted in a single level installation;  although, some are notably better than others ( the Raspberry PI is better than the Pine in this regard ).

POR must be controlled in 'stages' and the entire system must be protected against accidental power-off. This is obviously going to be more than a signle level control board attached to relays. Multiple level control and redundancy are required, and final power control is required. Things would be a lot easier if SBC(s) could be made reliable enough that ALL gpio pins would remain in the input state ( pullup or pulldown ) throughout the POR --- but, its not there yet.

Good evening. I correctly understand that this problem can not be solved, and for automation purposes it is suitable Raspberry PI?

[MarkHaysHarris777]

hi Artyom, whether any SBC will be a suitable controller depends on the characteristics of the control circuit, electrical dynamics and other things like security ( and others ).

Let's say you want to build a control circuit for your garage door that will automatically recognize just your car but no others. You have a radio chip on the windshield of your vehicle which can be 'read' from the eve of your house. cool. But here is the problem: what happens if your place has a power spike, or the power drops and later restarts. What happens to the door ? You don't want the door opening by itself on POR ( that would be a security problem ) and you don't want the controller to 'hang' on a power glitch either ( or else you can't get back in either ).

I have actually known people to build the above with an Arduino or a Raspberry PI, and all of them had to deal with this issue. Multi-level design is usually required ( or some fancy buffering like Pete was talking about ) becuase usually the I|O pins cannot be relied upon to maintain steady state during POR. Also, usually a good UPS is required too, so that power glitches don't afffect or shutdown or hang the system once started.

I believe you can build a reliable control system with the Pine ( I'm researching that the whole time I have had mine ) as long as you take POR into account, and have a good UPS or other system to handle power outages. BUT your system must not rely on any steady state during POR regardless of SBC; although, the RPi is ( in this instance ) may be more reliable in that situation. ( I'm just trying to be complete here )