Reset States of IO Pins Question...

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have what will likely turn out to be a foolish question, but I'm going to ask it anyway... :oops:

I'm considering re-designing one of my projects to use an AVR Mega controller (a Mega1280 or 2560, not sure which yet...) as a replacement for the 8052-based controller it currently uses - in order to integrate the 12-channel ADC into the controller and save a bit of board-space and cost.

My dilemma is that several of the pins will be driving relays for which it is *absolutely essential* that they not close before they are commanded... so I need to avoid transients at all costs.

I'm still poring over the datasheets, but am unable to find out what the pin-states are following a reset. If I'm reading them correctly, the pins default to a tri-state configuration, instead of the pulled-high state that the 8052 variants start in. While I doubt that a transistor would activate in such a state, the paranoid part of me is concerned.

Now, given the number of IO pins that are potentially available on these 100-pin devices, I can use optocouplers with the A and K leads each sent to a different pin... but I'd like to use transistors to drive the relays if at all possible.

Is it safe for me to assume that the pins start in an active-low state, and that any transistors I install will remain off until I program them to turn on?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Is it safe for me to assume that the pins start in an active-low state, and that any transistors I install will remain off until I program them to turn on?


I wouldn't, if you had those concerns. Floating pins--float. I'd weakly pull them to a save state.

x51 drives all pins when in reset? It's been a long time since I've worked with them but that sounds a bit strange.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The I/O's default to INPUTS at reset. They will high-Z floating inputs, so cannot assert either a 0 or a 1.
The transistor should remain off, but I would suggest having a 10K resistor from base to ground to ensure it is hard off.
Whilst the PORTx bits should also be clear at reset, it would be prudent to write 0's to the PORTx register before configuring the DDRx register for an output.

Welcome to AVR Freaks!
Edit.
Cross post! Too many Lee's!

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I'd weakly pull them to a save state.

Quote:
The transistor should remain off, but I would suggest having a 10K resistor from base to ground to ensure it is hard off.

I'll probably do that - a resistor doesn't take up a lot of space, and it's a good way to guarantee proper states.

Quote:
x51 drives all pins when in reset?

Except for Port0, which is used as the multiplexed address/data bus in expanded systems, all pins (on the Atmel versions, anyway, according to the datasheets...) have internal pull-ups that force them to a high state on reset.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd also add a charge pump circuit to control the power to the relays. With this you need to toggle a port pin to activate power to the relays. An extra level of redundancy so a failure wont cause the relays to activate.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Welcome on AVR forum.

RocketMan_Len wrote:
and that any transistors I install will remain off until I program them to turn on?

First of all you need to understand what a High-Z in a specification means. This tells you that Atmel guarantees (whatever that means) each IO can sink or source up to +-1uA then. Neither you, nor Atmel knows if this is sink or source. So you must design a relay circuit so that it operates even when it is +1uA or -1uA.

RocketMan_Len wrote:
instead of the pulled-high state that the 8052 variants start in

It is unlikely to relay on any technical detail of this kind in a serious project. When the power is turned on, the relays are powered first typically (as uC regulator needs to charge its output cap - it takes time). So the cpu is not even powered yet - pullup to ~0V will not change a thing..
After some time uC voltage rises and starts to boot up (lets assume the pullups are enabled then), crystal stabilizes (next 50ms). If a design relied on this pullup, then I am sure the relays would click initially.

Considering your nickname, another subject worth mentioning is the thing that is wired to the other side of the relay and the consequences of the fact the IO worked correctly, but your program tripped over its shoelace.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brutte wrote:
Welcome on AVR forum.

Thanks... :)

Quote:
So you must design a relay circuit so that it operates even when it is +1uA or -1uA.

The driver circuit I had in mind is attached. Should it not work, I could always fall back on using an optoisolator...

Quote:
When the power is turned on, the relays are powered first typically (as uC regulator needs to charge its output cap - it takes time). So the cpu is not even powered yet - pullup to ~0V will not change a thing..
After some time uC voltage rises and starts to boot up (lets assume the pullups are enabled then), crystal stabilizes (next 50ms). If a design relied on this pullup, then I am sure the relays would click initially.

Check my logic on the diagram I've attached. At power-up, the 12V rail becomes powered immediately. The PNP transistor is pulled high, and so is not conducting. The NPN transistor is pulled to ground, and thus is also not conducting. Thus, the circuit doesn't care how long it takes the controller to boot up and enable its internal pull-ups... since the transistors are already biased to an off-state.

Quote:
Considering your nickname, another subject worth mentioning is the thing that is wired to the other side of the relay and the consequences of the fact the IO worked correctly, but your program tripped over its shoelace.

Oh, this isn't going anywhere NEAR a regular launch event until I'm satisfied that I've worked out as many kinks as I can. Granted I'll have to test it under real-life conditions eventually... but rocket-fliers operate with the knowledge that mishaps occur, even with the most rigorously-tested systems. I may not be able to completely eliminate the risks, but I can minimize them. :)

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What about the R values? Looks fine, if R3 is not too big, and R2/R1 divider crosses Q1's Ube properly. But I am sure you know how to put right values without fire.

Just make sure R4 (or R2) do not break off before the launch.

One tip worth mentioning is that IOs have clamping diodes(all but /RESET upper). Although you will not read about them in datasheets, AN about zero-crossing detector tells those can withstand 1mA current.
You can also use a single bipolar transistor in your design, as IOs can easily sink/source 40mA. Lower part count means potentially higher reliability. Not mentioning easier diagnostics.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brutte wrote:
What about the R values? Looks fine, if R3 is not too big, and R2/R1 divider crosses Q1's Ube properly. But I am sure you know how to put right values without fire.

R2 and R4 would be in the 10K range... R1 and R3 would have to be determined by the hfe of the transistor in question - I haven't reached the point of calculating those yet. :)

Quote:
Just make sure R4 (or R2) do not break off before the launch.

No worries there, as this is intended for ground-support equipment rather than flight avionics.

Quote:
You can also use a single bipolar transistor in your design, as IOs can easily sink/source 40mA. Lower part count means potentially higher reliability. Not mentioning easier diagnostics.

The two-transistor solution gives me high-side switching, which I've been assuming is another benefit to safety. One thing I've never been able to figure out is what difference it would make... switching on the ground-side of the load, on on the +ve side. They both look functionally the same... and if the semiconductor fails, won't it more likely fail as a short-circuit than as an open one? So either way - if the transistor melts, the relay will be activated and closed anyway... seems like a 'six of one, half a dozen of the other' type of choice.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was suggesting you have a high side drive via a charge pump as a form of redundancy as well as the individual low side drive. Transistors do tend to fail short circuit as do diodes, so the general idea is that you size the devices such that a worst case overload would not cause a failure. With the high side I suggested,for the relay to be activated without the micro's consent would require two failures. You could also have the micro test each output via feeding the output of the transistors back into the micro. That way the micro can detect a failure. Not all that hard and a few R's and C's to add along with a bit of code. BIST - built in self test!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RocketMan_Len wrote:
The two-transistor solution gives me high-side switching, which I've been assuming is another benefit to safety.

Then use a negative voltage LDO (79XX or LM337) for uC if that bothers you :)
Kartman wrote:
BIST - built in self test!

I have seen such a "safety conscious" embedded device only once. It had three symmetrical uCs, special passive elements which were designed to fail only into a known state, many signals were sent not as standard IO signaling, but as a PWM generated in software + separating transformer (if anything went wrong, PWM disappeared).

If you need high level of safety, perhaps you should use ARM Cortex R series.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's various levels of safety. Thre three micros is usually referred to as TMR ( triple multiple redundant) which is fine if you're controlling something that might kill a number of people. Nevertheless, with the techniques I've outlined, youcan have something that is a lot more tolerant of failure. It also tests itself. One of my products ended up on my desk reporting a relay failure. It wasn't lying - the board had been dropped and the case of the relay pushed in and activating the contacts. The board failed safe. A little bit of work and some careful thinking can yield a more reliable product without going to the extremes of TMR.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
I was suggesting you have a high side drive via a charge pump as a form of redundancy as well as the individual low side drive.

Interesting idea - I hadn't thought of that... primarily because I'm not very familiar with charge-pumps, and wouldn't really know how to implement one. :oops:

Quote:
You could also have the micro test each output via feeding the output of the transistors back into the micro. That way the micro can detect a failure. Not all that hard and a few R's and C's to add along with a bit of code. BIST - built in self test!

I have this incorporated into the design already - after a fashion. A voltage-divider coming off the SPDT relay contacts sends a signal via the ADC to indicate whether the contacts are in their 'off' state or their 'on' state. The processor would then send an alert that the contacts are faulted. I had originally designed it so that the relay could not be activated while the system was in Test-mode... so the drivers themselves would not have fault-detection. But with a simple change, I can allow testing of the drivers as well. :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Question, Kartman...

Doing a Google search for a suitable charge-pump, I came across this device, which looks to be a fully-integrated solution to the problem.

http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=IPS7091GTRPBFCT-ND

Your thoughts...?