7 replies to this topic

[PhilG]

I have noticed that the IO pins om my N+ go to about 1V during reset/powerup. When the program starts to run they go to the expected states. This is real problem if an output port is driving something important like the roof of an observatory. A 10k pulldown helps but not enough so that it doesn't try to turn on an NPN, MOSFET, or optoisolator. Why is this happening? I would think they would come up tristated.

[Mario Vernari]

Starting from reset, until your program port assignment, any I/O is placed in a input-state, with pull-up enabled. This is the most reliable condition for the MCU, being unknown a-priori what's connected to. This feature is by design from the Atmel manufacturers. Consider the alternative solution that would have been chosen: by placing an I/O as an output (either at low or high level), would resulted in a potential collision if you connected another output of some custom logic (i.e. your goal is to consider that pin as an input). Thus, it's better to place as an input: let's avoid any pull-up, but...what would be the voltage if that pin won't be connected (i.e. let it floating)?...Unpredictable. That is another bad condition to avoid, thus the only (and best) way to guarantee a reliable condition is to place any I/O as an output, with pull-up enabled. A pull-down resistor is *NOT* a good solution, because together with the internal pull-up will bring the pin to a half-a-way voltage, which should not allowed. Your "problem" has already been discussed when someone noticed his relays turning on for a brief time during the reboot. You have (mainly) two choices: Your activation logic works at "low" level, thus any output will turn on the appliance connected when the voltage is ZERO. This is a common practice, derived from the old-school of the TTL-logic, which was able to drive much more current at low-level, and most of the circuits had a negative-logic design. Another way, more general and more oriented toward *THIS* specific problem, is to provide a "main enable" signal, which puts *ANY* critical I/O driver in a well defined state. This solution is maybe complex than the first one, but it's targeting the inability to obtain a reliable signal until your program starts. Bear in mind that "your program starts" is a relative concept: you, and you only, know *WHEN* all the I/O have definitely configured. A basic example to solve the second option, is using an AND-gate: one input is coming from the real I/O, the other from the "main enable" (which should be inverted, though). During reboot any I/O is high, but the "main enable" will be low, because the NOT, thus the AND output will be also low. At this point, no matter what's the level on the I/O pin, until the "main enable" is "unmanaged". When your program will be sure to have configured properly any I/O, the "main enable" can be pulled high, and the appliances driven correctly. Hope it helps. Cheers

[PhilG]

Mario, Thanks for the reply. It makes no sense to me that the Atmel IO lines are put in the input-with-pullup state during power-up. If they were tri-stated or inputs without pullups, then I could manage the IO states with simple pullups or pulldowns until the program takes control. That's a lot simpler than using external logic to 'fix' the uP IO unmanaged state and it is, I think, the way PICs work. I will change my IO devices to work with active low rather than high. I was mislead down the path of connecting the load to ground by looking at the how the Sparkfun screwsheild connects it's yellow LED between D13 and Ground. It, of course, lights dimly during reset.

[Robert L.]

Mario,
Thanks for the reply. It makes no sense to me that the Atmel IO lines are put in the input-with-pullup state during power-up. If they were tri-stated or inputs without pullups, then I could manage the IO states with simple pullups or pulldowns until the program takes control. That's a lot simpler than using external logic to 'fix' the uP IO unmanaged state and it is, I think, the way PICs work. I will change my IO devices to work with active low rather than high. I was mislead down the path of connecting the load to ground by looking at the how the Sparkfun screwsheild connects it's yellow LED between D13 and Ground. It, of course, lights dimly during reset.

I have had good luck pulling an output low with a 1K resistor. That way the voltage stays low enough during reset time, that my output transistor (whose base is driven by the pin) never fires, until the port is changed to an output and driven high. The pullup resistor is not strong enough to overcome the 1K external.

[georgejh]

Additional to what Mario suggests you may look into this tutorial where I show alternative methods to solve this problem. In next version NAND and NOT gates will be included too.

[cross6]

A 2.2K pulldown resistor wil solve this issue.

[Stefan W.]

A pulldown is not a good solution, as Mario has explained. I don't know why this keeps getting suggested. What you're having effectively then is

o 3v3
  |      
 .-.     
 | |     
 | | 15k 
 '-'     
  |      
  o-----o GPIO
  |      
 .-.     
 | |     
 | | 2k2  
 '-'     
  |      
  o GND

(if i remember the pullup value correctly) which will mean that you read about 0.42V at boot, which might not be logic low for everything. Also, in this setup, you waste ~1.5mA when you want to drive the pin high later ...

[cross6]

You're right, I didn't stop to consider the pull-up resistor.

In that case, a schmitt-trigger or 'master-enable' method as mentioned earlier using gates.

A pulldown is not a good solution, as Mario has explained. I don't know why this keeps getting suggested. What you're having effectively then is

o 3v3
  |      
 .-.     
 | |     
 | | 15k 
 '-'     
  |      
  o-----o GPIO
  |      
 .-.     
 | |     
 | | 2k2  
 '-'     
  |      
  o GND

(if i remember the pullup value correctly) which will mean that you read about 0.42V at boot, which might not be logic low for everything. Also, in this setup, you waste ~1.5mA when you want to drive the pin high later ...