I/O states pre-POR

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

I'm using the ATtiny416.  POR kicks in somewhere between 1.4 and 1.8 volts as long as Vdd is rising slowly enough.  But I've got some FETs on the board that can turn on at 1.0 volt.  I've got pull downs on the FET gates, but if the I/O pins of the ATtiny416 were to be driven high while Vdd is rising from 0 to 1.4 volts even for a few microseconds, it could short out my H-bridge.  So my question is, "Are the I/O pins undefined while Vdd is rising from 0 to POR?"  I was using a Motorola DSP56F805 years ago, and some of the I/O pins would be driven high briefly during power up, and every once in awhile that would smoke an H-bridge.  At Texas Instruments, we had a few 7400 series logic gates which had been analyzed and proven to remain in a known state during power up.  We would use those gates for power-up related functions. I've asked MicroChip technical support this question, but my technical support person doesn't seem to understand the question.  She keeps telling me that the I/O pins remain tri-stated until POR is released.

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

IO pins are inputs unless told otherwise by your code.

 

As Vdd rises above the POR threshold a timer starts and then when that expires the internal RESET signal is generated. One of the things it does is reset all the IO registers to their power-up state, ie inputs.

 

If the BOD is enabled then as the power fails an internal reset is generated which will again reset IO to inputs.

 

The direction of an IO is controlled by a D-type latch. There's no reason to suspect that they aren't designed to power up in a known state with the IO set as inputs.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Douglas Holub wrote:

...as long as Vdd is rising slowly enough...

 

Just be sure it's not too slow. Most chips have a maximum risetime requirement for their power to guarantee correct operation.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Use an external supervisor/reset-controller to keep the microcontroller safely in Reset until the supply has stabilised ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

A BOD level above 2V should take care of the problem.

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

Douglas Holub wrote:
I'm using the ATtiny416.  POR kicks in somewhere between 1.4 and 1.8 volts as long as Vdd is rising slowly enough.

Is this a concern because your testing shows it to be a problem, or are you just concerned because this has bitten you before?

As stated above, the AVR i/o pins are inputs(hi-z) until told to change, as long as the BOD level is set to the proper level, I would not worry about this, unless proven otherwise.

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

I appreciate your feedback.  But since as Vdd rises "one of the things it does is reset all the IO registers to their power-up state, ie inputs.", you've got to wonder why it bothers to do that if they are already guaranteed to be inputs.

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

Thanks.  I'll try not to worry.  But I was bitten before.  I'll probably add an external reset circuit if I can't get a solid answer from MicroChip.

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

Douglas Holub wrote:

I appreciate your feedback.  But since as Vdd rises "one of the things it does is reset all the IO registers to their power-up state, ie inputs.", you've got to wonder why it bothers to do that if they are already guaranteed to be inputs.

 

I would think it's best practice to set everything to a known state. 

 

The datasheet indicates after reset, all pins are input (tri-stated)...which is what the folks you spoke to said as well. 

 

Why not hook up a logic analyzer to your 416 ports, and see what they do when power is applied?

 

If you're worried about a "Freak bit-flip" there isn't much you can do about that....any project can be hit by a stray cosmic ray and get a bit flipped.

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

Maybe I'm missing the point, but I think Doug's question is valid, and is not answered within the data sheet.

The question is what happens to an I/O pin's output driver PRIOR to POR, when V+ is initially applied and is rising from 0.0 V up towards the POR value?

 

Perhaps the V+ bus level applied to the output stage of the I/O pin driver is too low at that point to turn on the H-Bridge driver, but one can't know that without seeing the H-bridge driver schematic.

 

Adding an external Reset chip is great, for what it does.

But its function is to hold the uC in reset until Vcc has stabilized at its regulated voltage level.

That still doesn't answer, or solve the question above.

It doesn't guarantee the state of the I/O pin driver prior to the V+ Bus being alive enough for the driver hardware to be in a known and defined state.

 

I think this is actually a very interesting question, albeit one that likely applies to a very narrow period of time.

 

This sounds like one of the deep secretes of the AVR that Ralph would enjoy investigating.

 

Regardless of the Tech Support answer, I think it would be interesting to build a hardware glitch detector, windowed for the time interval of interest, and let it cycle the system several 10's of thousands of times, with several different power supplies and micros connected to the test bed.

Doing so would not guarantee the micro's performance.

 

But if you caught a glitch it would give you the grounds for being concerned, and a solid foundation for pushing tech support for an answer to the question that was asked, not an answer to the question that is usually asked, but isn't relevant to today's question.

 

JC

 

Edit:  Perhaps if onw is suing an H-driver chip, and not building one from scratch, it has its own Enable Pin to hold its output driver in a known state during power on.

In that case an external POR chip might be of help.

 

 

Last Edited: Mon. Jun 22, 2020 - 07:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

You're probably over-thinking this. In that grey area of Vcc before the chip reset threshold, the FETS driving the AVR pin won't have much, if any gate drive so will look high impedance. At worst they might begin to turn on slightly but then look like a very weak pull-up or pull-down.

 

In similar cases to yours I simply define the pin voltage whilst in reset with an external resistor.

 

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

"That still doesn't answer, or solve the question above." 

I've found a reset generator that is guaranteed to work when Vcc is only 0.8 volts.  Or I could just use a resistor and a cap and a diode on the reset pin.  I was just hoping to avoid adding the extra circuitry if this was something that Microchip had already analyzed and answered. (It's a cost sensitive, high volume product, and I'm running out of PCB space.)

 

Thanks to everyone for the helpful suggestions.

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

DocJC wrote:

 

Edit:  Perhaps if onw is suing an H-driver chip, and not building one from scratch, it has its own Enable Pin to hold its output driver in a known state during power on.

In that case an external POR chip might be of help.

 

 

 

And you're back to the same problem: What's the behavior / state of that "Enable" pin when VCC is rising, but below the H-Bridge driver's required voltage? It's turtles all the way down.

 

 

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

I've always put a pulldown (or pullup, if pChan) (10k) on the FET's gate when faced with this situation.  I've never seen any unwanted spurious behavior on power up of an AVR uC when doing this.

Letting the smoke out since 1978

 

 

 

 

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

>POR kicks in somewhere between 1.4 and 1.8 volts

 

It would seem to me, that POR is a state you are in up until the POR threshold, and when in POR state you get 'reset' logic.

 

 

 

This is from a 417 datasheet (with TCD)-

A power-on-reset (POR) is generated by an on-chip detection circuit. The POR is activated when the VDD rises until it
reach the POR treshold voltage. The POR is always enabled and will also detect when the VDD falls below the
treshold voltage.

All logic is reset on POR. All fuses are reloaded after the reset is released. While POR is active, TCD pin override
functionality is not available

 

Since they seem to be big on 'functional safety' lately, or whatever they want to call it, you can also look what they think is 'safe' (there may be better documents, this is just picked at random)-

 

http://ww1.microchip.com/downloads/en/Appnotes/Functional-Safety-Demonstrator-Using-ATtiny3217-DS00002541A.pdf

During a power-up of a device, it is important to give the entire device a reset to put everything in a
known state. It is equally important not to start executing code from Flash before the Flash and digital
logic have sufficient power. When the voltage rises, the POR is activated and will hold the device in reset

until the voltage is above a fixed threshold value. The POR will remain enabled as long as the device is powered.

also see Figure 2-5 in that same document, and indicates the POR is active below the POR threshold, how far I don't know but would guess far enough.

 

They are big on 'functional safety' lately, so you would think they would be touting the need for an external reset controller if it was needed. It makes little sense they go through all this trouble to check everything else, but allow the lasers in the factory to go unleashed just by feeding a low voltage to the mcu.

 

 

 

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

But I've got some FETs on the board that can turn on at 1.0 volt.

Don't use fets that turn on so easily...say you found some utopia fets that turned on at 0.05 volts...you'd have much higher risk of trouble...if you use fets that turn on (actually "start to turn on") at 2.5 volts, the risk is a  lot less.

 

Also, fets that turn on at real low voltage have significant tradeoffs, that make them worse in other aspects....so, do you need such sensitive fets?

 

while Vdd is rising from 0 to 1.4 volts even for a few microseconds, it could short out my H-bridge.

Depending on the power levels (watts, KW) , or safety (is this running a crane?), you may want to add some logic anyway...never assume the software won't go corrupt (even at normal 5V supply) and might try turning on all the transistors in your h-bridge...fusies , current monitor/gate shutoffs/cross conduction prevention components are recommended depending on the disaster level.

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Mon. Jun 22, 2020 - 11:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And you're back to the same problem: What's the behavior / state of that "Enable" pin when VCC is rising,

Almost, but not quite.

If you are using a H-Driver chip then the power up operation of the output drivers is the design responsibility of the chip designer.

And clearly they should have taken precautions to prevent the possibility of a shoot-through on power up for their chip.

 

The issue is where is the burden to guarantee no shoot-through?

If one uses the micro and stand-alone driver circuitry, its up to the designer.

In which case the issue raised by the OP, especially having been burned on this issue before, is up to his design.

 

If he uses a H-driver an the recommended design, particularly if it includes an enable type functionality, then the issue is shifted to the H-Driver chip designer/manufacturer.

 

JC  

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

"It would seem to me, that POR is a state you are in up until the POR threshold, and when in POR state you get 'reset' logic."

 

I think you're right.  Vpor is the voltage at which reset is released, not the voltage at which reset becomes active.  So the chip is in reset from 0 volts to Vpor.  That does make more sense.  The chip can run at 1.8 volts, and max Vpor is 1.8 volts.  It would be strange to activate reset at an operating voltage level.  I'll confirm it with Microchip.  Thanks a million.

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

 Vpor is the voltage at which reset is released

Of course, as you mention, even if the chip is in "reset" it could do funny things when the voltage is too low for the chip to function normally (say at 1 V).   Hopefully, they have it well-covered, but sometimes it is hard to read into that specific info as to whether it stays in tri-state below that min allowable chip voltage (separate from the POR voltage).  

 

Various forms of maddness found for some chips:

 

Here, a chip is kept in permanent reset & still creates a glitch:

I am experiencing a  problem with PIC16F1777. Even I keep the chip in the reset state (by grounding MCLR#) there is a glitch in the gpio output while power on ( pull-down resistors where added but no effect).
There is a Flash LED connected to this gpio through a driver, every time  I power on the device LED flashes once even the chip is in the reset state. 

-----------------------

There is no power sequencing requirement needed to ensure the device is in the proper state after reset or to prevent the I/Os from glitching during power up or power down (GPIO19, GPIO26–27, GPIO34–38 do not have glitch-free I/Os). No voltage larger than a diode drop (0.7 V) above VDDIO should be applied to any digital pin (for analog pins, this value is 0.7 V above VDDA) before powering up the device. Voltages applied to pins on an unpowered device can bias internal p-n junctions in unintended ways and produce unpredictable results. ​​​​​​​

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Tue. Jun 23, 2020 - 03:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

12.3.2.1.1 Power-On Reset (POR)
The POR is activated when Vdd rises until it reaches the POR threshold voltage.

 

Microchip technical support confirmed it. Sorry for the confusion.  I had read that paragraph multiple times; I guess I just interpreted it the way I assumed it was working.

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

note they somewhat skirt the issue (probably unintentionally)

 

A power-on-reset (POR) is generated by an on-chip detection circuit. The POR is activated when the VDD rises until it reach the POR treshold voltage.

All logic is reset on POR. All fuses are reloaded after the reset is released. While POR is active, TCD pin override functionality is not available.

 

The device must operate within the ratings listed in this section (min 1.8V) in order for all other electrical characteristics and typical characteristics of the device to be valid.

 

So all they claim is that the logic will be given a reset.  They don't explicitly claim that the output will be low during the reset while the chip is powered below it's minimum allowable operating voltage.

In all likelihood, it is probably true that the output will remain low; however there is a thin window of opportunity in the interpretation to escape this constraint.

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

avrcandies wrote:
In all likelihood, it is probably true that the output will remain low; however there is a thin window of opportunity in the interpretation to escape this constraint.

No, as all pins are inputs (hi-z) they will float, unless you have pull downs on the lines you want to be low.

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

There is that whole "zone of uncertainty" below and around the internal FET threshold levels. In that area, I doubt that anybody can guarantee anything. But, isn't the same true of your external hardware?

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

No, as all pins are inputs (hi-z) they will float, unless you have pull downs on the lines you want to be low.

How do you know that, from 0V on up?   At 1V certain transistors may come on and others staying off. Below the proper minimum operating voltages (1.8V), where is it stated what is happening in the chip?  Upon powerup into the operating zone they will certainly be reset (as inputs), but what about the journey getting there? 

 

It would certainly be hopeful that they are maintained, at best, it seems somewhat inferred. You can see it is not always the case:

I am experiencing a  problem with PIC16F1777. Even I keep the chip in the reset state (by grounding MCLR#) there is a glitch in the gpio output while power on ( pull-down resistors where added but no effect).

Why couldn't the same happen with an AVR?

 

Here is a gate example form TI:

The SN74LVC1G11 is only guaranteed to operate correctly between 1.65 and 5.5V by the datasheet. I don't have test data for this device below 1.65V for operation.

That being said, typically the output will remain low during power-up if the inputs are in a defined low state, however there are some cases where small glitches have been seen on some logic devices. Typically these happen right around the turn-on voltage for the FETs (~850mV) and will usually track the supply for a short time before reverting back to ~0V.

 

 

Here's a bells & whistles, giving an overload of things they need to consider:   https://www.analog.com/en/analog-dialogue/articles/powering-ics-on-and-off.html  

Probably just as easy to suck it up and pland to have a 10's of nanosec glitch. 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Tue. Jun 23, 2020 - 07:50 PM