Reasons for having MCU pin-states default to pull-up/down out of resetHow to configure an ARM GPIO port (STR9) to an alternate function?Recommendation for default settings for unused pins on an STM32 (ARM Cortex M3) - pull up/pull down?Why would an input pin have both a pull-up and pull-down resistor?Need of External Pull Up/Pull Down for Processor I/O pinsPullup or direct drive when handling active low inputs/resets?Pull-up and Pull-down Resistor Usage on Input or Output MCU PinsTurn pull-up into pull-downPull-up vs Pull-down on enable pinPrevent a floating output to PWM input on MCU resetPull-up vs Pull-down for contact switch?

Why can't I get pgrep output right to variable on bash script?

How do you justify more code being written by following clean code practices?

What properties make a magic weapon befit a Rogue more than a DEX-based Fighter?

Weird lines in Microsoft Word

Offset in split text content

Can a Knock spell open the door to Mordenkainen's Magnificent Mansion?

"Marked down as someone wanting to sell shares." What does that mean?

How do I lift the insulation blower into the attic?

What is the meaning of "You've never met a graph you didn't like?"

Why didn’t Eve recognize the little cockroach as a living organism?

Would this string work as string?

Not hide and seek

How do you say "Trust your struggle." in French?

Taking the numerator and the denominator

Is divisi notation needed for brass or woodwind in an orchestra?

Connection Between Knot Theory and Number Theory

Friend wants my recommendation but I don't want to give it to him

Calculate Pi using Monte Carlo

Hashing password to increase entropy

What can I do if I am asked to learn different programming languages very frequently?

How to get directions in deep space?

Center page as a whole without centering each element individually

What should be the ideal length of sentences in a blog post for ease of reading?

Travelling in US for more than 90 days



Reasons for having MCU pin-states default to pull-up/down out of reset


How to configure an ARM GPIO port (STR9) to an alternate function?Recommendation for default settings for unused pins on an STM32 (ARM Cortex M3) - pull up/pull down?Why would an input pin have both a pull-up and pull-down resistor?Need of External Pull Up/Pull Down for Processor I/O pinsPullup or direct drive when handling active low inputs/resets?Pull-up and Pull-down Resistor Usage on Input or Output MCU PinsTurn pull-up into pull-downPull-up vs Pull-down on enable pinPrevent a floating output to PWM input on MCU resetPull-up vs Pull-down for contact switch?













6












$begingroup$


On many MCUs, pin-states default to tri-stated (a.k.a. analog inputs) when the MCU resets so as to not affect the circuits they are connected to until software configures the pins. The tri-stated pins also allow the HW designer to choose the pull state of each pin on a case-by-case basis in function of the underlying circuitry.



However, there are some MCUs (and SoCs) that default their pins to instead activate an internal pull-up/down. For example, the LPC845 defaults all pins to pull-ups coming out of reset.
LPC845 Datasheet Section 8.11.1



Is there a reason defaulting pins to pull-up/down is preferable to tri-stated (other than the possible incremental power savings when coming out of a reset, or the marginal BOM cost savings)?



If anything, I rarely find that pins should be pulled-up coming out of reset (I typically need to pull them down, if at all).










share|improve this question











$endgroup$







  • 1




    $begingroup$
    I'd probably want that behavior to be configurable with fuses for the device, during programming. That's my thought, right now.
    $endgroup$
    – jonk
    21 hours ago






  • 3




    $begingroup$
    Sounds like a good chip. The real question is why the vast majority of MCUs leave them in tri-state/inputs, exposing the pins to EMI and ESD during MCU boot-up. Because we all like EMC tests failing and ESD-damaged ICs, right?
    $endgroup$
    – Lundin
    14 hours ago











  • $begingroup$
    @Lundin This is an interesting point. I could see EMI being an issue if the pins are not externally pulled, but how would ESD be mitigated by defaulting pins to a certain pull state coming out of reset? Aren't the input pin diodes sufficient?
    $endgroup$
    – TRISAbits
    10 hours ago















6












$begingroup$


On many MCUs, pin-states default to tri-stated (a.k.a. analog inputs) when the MCU resets so as to not affect the circuits they are connected to until software configures the pins. The tri-stated pins also allow the HW designer to choose the pull state of each pin on a case-by-case basis in function of the underlying circuitry.



However, there are some MCUs (and SoCs) that default their pins to instead activate an internal pull-up/down. For example, the LPC845 defaults all pins to pull-ups coming out of reset.
LPC845 Datasheet Section 8.11.1



Is there a reason defaulting pins to pull-up/down is preferable to tri-stated (other than the possible incremental power savings when coming out of a reset, or the marginal BOM cost savings)?



If anything, I rarely find that pins should be pulled-up coming out of reset (I typically need to pull them down, if at all).










share|improve this question











$endgroup$







  • 1




    $begingroup$
    I'd probably want that behavior to be configurable with fuses for the device, during programming. That's my thought, right now.
    $endgroup$
    – jonk
    21 hours ago






  • 3




    $begingroup$
    Sounds like a good chip. The real question is why the vast majority of MCUs leave them in tri-state/inputs, exposing the pins to EMI and ESD during MCU boot-up. Because we all like EMC tests failing and ESD-damaged ICs, right?
    $endgroup$
    – Lundin
    14 hours ago











  • $begingroup$
    @Lundin This is an interesting point. I could see EMI being an issue if the pins are not externally pulled, but how would ESD be mitigated by defaulting pins to a certain pull state coming out of reset? Aren't the input pin diodes sufficient?
    $endgroup$
    – TRISAbits
    10 hours ago













6












6








6


1



$begingroup$


On many MCUs, pin-states default to tri-stated (a.k.a. analog inputs) when the MCU resets so as to not affect the circuits they are connected to until software configures the pins. The tri-stated pins also allow the HW designer to choose the pull state of each pin on a case-by-case basis in function of the underlying circuitry.



However, there are some MCUs (and SoCs) that default their pins to instead activate an internal pull-up/down. For example, the LPC845 defaults all pins to pull-ups coming out of reset.
LPC845 Datasheet Section 8.11.1



Is there a reason defaulting pins to pull-up/down is preferable to tri-stated (other than the possible incremental power savings when coming out of a reset, or the marginal BOM cost savings)?



If anything, I rarely find that pins should be pulled-up coming out of reset (I typically need to pull them down, if at all).










share|improve this question











$endgroup$




On many MCUs, pin-states default to tri-stated (a.k.a. analog inputs) when the MCU resets so as to not affect the circuits they are connected to until software configures the pins. The tri-stated pins also allow the HW designer to choose the pull state of each pin on a case-by-case basis in function of the underlying circuitry.



However, there are some MCUs (and SoCs) that default their pins to instead activate an internal pull-up/down. For example, the LPC845 defaults all pins to pull-ups coming out of reset.
LPC845 Datasheet Section 8.11.1



Is there a reason defaulting pins to pull-up/down is preferable to tri-stated (other than the possible incremental power savings when coming out of a reset, or the marginal BOM cost savings)?



If anything, I rarely find that pins should be pulled-up coming out of reset (I typically need to pull them down, if at all).







microcontroller gpio pullup pulldown tri-state






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 21 hours ago







TRISAbits

















asked 22 hours ago









TRISAbitsTRISAbits

6461623




6461623







  • 1




    $begingroup$
    I'd probably want that behavior to be configurable with fuses for the device, during programming. That's my thought, right now.
    $endgroup$
    – jonk
    21 hours ago






  • 3




    $begingroup$
    Sounds like a good chip. The real question is why the vast majority of MCUs leave them in tri-state/inputs, exposing the pins to EMI and ESD during MCU boot-up. Because we all like EMC tests failing and ESD-damaged ICs, right?
    $endgroup$
    – Lundin
    14 hours ago











  • $begingroup$
    @Lundin This is an interesting point. I could see EMI being an issue if the pins are not externally pulled, but how would ESD be mitigated by defaulting pins to a certain pull state coming out of reset? Aren't the input pin diodes sufficient?
    $endgroup$
    – TRISAbits
    10 hours ago












  • 1




    $begingroup$
    I'd probably want that behavior to be configurable with fuses for the device, during programming. That's my thought, right now.
    $endgroup$
    – jonk
    21 hours ago






  • 3




    $begingroup$
    Sounds like a good chip. The real question is why the vast majority of MCUs leave them in tri-state/inputs, exposing the pins to EMI and ESD during MCU boot-up. Because we all like EMC tests failing and ESD-damaged ICs, right?
    $endgroup$
    – Lundin
    14 hours ago











  • $begingroup$
    @Lundin This is an interesting point. I could see EMI being an issue if the pins are not externally pulled, but how would ESD be mitigated by defaulting pins to a certain pull state coming out of reset? Aren't the input pin diodes sufficient?
    $endgroup$
    – TRISAbits
    10 hours ago







1




1




$begingroup$
I'd probably want that behavior to be configurable with fuses for the device, during programming. That's my thought, right now.
$endgroup$
– jonk
21 hours ago




$begingroup$
I'd probably want that behavior to be configurable with fuses for the device, during programming. That's my thought, right now.
$endgroup$
– jonk
21 hours ago




3




3




$begingroup$
Sounds like a good chip. The real question is why the vast majority of MCUs leave them in tri-state/inputs, exposing the pins to EMI and ESD during MCU boot-up. Because we all like EMC tests failing and ESD-damaged ICs, right?
$endgroup$
– Lundin
14 hours ago





$begingroup$
Sounds like a good chip. The real question is why the vast majority of MCUs leave them in tri-state/inputs, exposing the pins to EMI and ESD during MCU boot-up. Because we all like EMC tests failing and ESD-damaged ICs, right?
$endgroup$
– Lundin
14 hours ago













$begingroup$
@Lundin This is an interesting point. I could see EMI being an issue if the pins are not externally pulled, but how would ESD be mitigated by defaulting pins to a certain pull state coming out of reset? Aren't the input pin diodes sufficient?
$endgroup$
– TRISAbits
10 hours ago




$begingroup$
@Lundin This is an interesting point. I could see EMI being an issue if the pins are not externally pulled, but how would ESD be mitigated by defaulting pins to a certain pull state coming out of reset? Aren't the input pin diodes sufficient?
$endgroup$
– TRISAbits
10 hours ago










5 Answers
5






active

oldest

votes


















8












$begingroup$

Because it's good practice to never leave logic pins purely floating.
Brief TI Overview
Detailed TI overview
Amusing dramatized war story of a real-world example






share|improve this answer









$endgroup$












  • $begingroup$
    I completely agree. Floating pins are indeed a bad thing for power consumption. But any well behaved firmware should set all unused pins to a known state, so the power loss would only occur coming out of a reset (and this loss can be eliminated by placing external pulls). So is the idea that by giving a default state to a pin (pull-up/down) the FW needs less massaging to get lower power numbers?
    $endgroup$
    – TRISAbits
    21 hours ago






  • 1




    $begingroup$
    I think you've cut to the heart of the matter here. If the firmware is well-behaved and/or the hardware designer had the good sense to apply proper pull-ups or pull-downs, then there would be absolutely no need for this type of initialization. And I'd guess that's why not all chip designers do this. It's all a matter of philosophy -- do you want to presume your users are smart enough to do The Right Thing, or do you want to protect them if they don't? It could be argued either way...
    $endgroup$
    – Mr. Snrub
    21 hours ago










  • $begingroup$
    Certain MCUs have their digital input buffer logic disabled coming out of reset (e.g. PIC12/16/18), which presumably is intended to prevent leakages caused by shoot-through? If so, that would be an alternative to forcing pins in a certain known-state.
    $endgroup$
    – TRISAbits
    11 hours ago






  • 1




    $begingroup$
    BTW, you mentioned leakage currents, but as illustrated in the "amusing dramatized war story", my bigger worry would be oscillations. Leakage currents will go away once the FW sets the pin to a good state, but if a floating pin oscillates then there is the danger of it causing the logic to go into an invalid state.
    $endgroup$
    – Mr. Snrub
    8 hours ago






  • 1




    $begingroup$
    I really mean to say that oscillation on an input pin at any time, whether in reset or not, is probably Bad News. Yes if the oscillation occurred during the reset process, then I would be gravely concerned that the reset process may not fully initialize things to a known good state.
    $endgroup$
    – Mr. Snrub
    7 hours ago


















5












$begingroup$

Other answers have given general reasons why a chip maker might make the choice to enable pull-ups by default. However, in the specific case of LPC845, there is an additional reason: it has specialized FAst Initialization Memory (FAIM) that can be used to set the state immediately after reset:




The FAIM contents provide a user-programmable initial configuration for aspects of the
microcontroller, which take effect immediately after reset, before code begins to run. For
instance, the standard I/O pads normally come out of reset with the internal pull-ups
enabled. In some systems this may cause excess current to flow, until software can
reconfigure the pads. However, by programming the FAIM appropriately, every pad's reset
configuration can be customized.




(LPC84x user manual section 4.2)



Thus they've chosen the safe (from power usage and EMI point of view) default, while allowing more advanced users to customize the setting.






share|improve this answer









$endgroup$












  • $begingroup$
    The downside with the FAIM is that it requires an additional programming step to set it up front, which means that your design should survive the incorrect pull-state until the FAIM is updated. Alternatively you can install a stronger external pull to overdrive the default internal setup, but you've now introduced a perpetual power loss through the external pull. I guess you can't have your cake and eat it too.
    $endgroup$
    – TRISAbits
    11 hours ago










  • $begingroup$
    @TRISAbits Yeah. But after all even if it were tristated, you'd need the external pulldown on important pins, and if it is pulling to the default state, the average loss is not so much.
    $endgroup$
    – jpa
    7 hours ago










  • $begingroup$
    The point I was (poorly) making is that the external pull will have to be stronger than otherwise required in order to overdrive the internal pull. If the pins were tri-stated then the pull could be weaker, which would result is less power loss through the external pull.
    $endgroup$
    – TRISAbits
    5 hours ago


















4












$begingroup$

Back in the days there were Intel 8051 microcontrollers that only had open drain I/O pins, so most of the time you needed external pull-ups anyway to do useful things like connecting to pushbuttons or controlling CMOS inputs of other chips. This is most likely to have easy redesign of such boards with a modern microcontroller, or people from that era that are accustomed to designing with pulled-up open-collector I/Os. Back in the day, you mostly needed pull-ups if anything, and rarely pull-downs.






share|improve this answer









$endgroup$












  • $begingroup$
    That's a really interesting bit of insight, and explains why a lot of logic chips have active-low output-enable pins. Active-high logic doesn't mesh as well when the default pull-state is high. As an aside it also doesn't mesh well when directly connected to the gate of a NMOS, unless you want the transistor to turn on by default.
    $endgroup$
    – TRISAbits
    11 hours ago






  • 1




    $begingroup$
    Also other chips of that era have active signals when low. TTL chips (74XX and 74LSXX series for example) can pull low stronger than push high. Therefore fast falling edge is sharper and more defined than slow exponentially rising edge. Also small currents flow in and out of chip inputs as they are not so high impedance. Therefore, pull-ups are sometimes necessary, and pull-ups can be weaker than pull-downs, so that's why you have active low logic with pull-ups, with pushbuttons grounding the inputs and outputs turning on LEDs by grounding the LED via resistor.
    $endgroup$
    – Justme
    7 hours ago


















3












$begingroup$

From a systems point of view, having the pins start in a defined state is a benefit. For example, a motor might be attached that shouldn't be activated without command. Peripherals usually expect their interfaces to be in a certain state, and starting in high-Z may not provide the required state. As the internal pull ups/downs in a typical microcontroller are relatively weak, they may be overridden by a stronger external pull up/down where required. As an additional note, it is nice to see in the datasheet what the expected behaviour of the pins is, this is sometimes not included..!






share|improve this answer









$endgroup$








  • 1




    $begingroup$
    The problem with providing an external pull-up when an internal one is enabled is two-fold: [1] The external pull has to be properly sized to be far stronger (good rule of thumb is at least 10x). Otherwise you will create a voltage divider, which can set the voltage into that middle no-mans-land zone. [2] The stronger external pull introduces a continuous power loss (if the pin state is frequently opposite the pull direction), which will quickly consume more power than any loses from having tri-stated pins out of reset.
    $endgroup$
    – TRISAbits
    11 hours ago










  • $begingroup$
    @TRISAbits Agreed on both points. Not that desirable to override, but most internals are 50-100K so not disasterous. Read the manual, as ever :)
    $endgroup$
    – awjlogan
    11 hours ago











  • $begingroup$
    @TRISAbits And also it's not about power in this example, it's about how the wider system interacts at reset, not just the MCU.
    $endgroup$
    – awjlogan
    11 hours ago



















2












$begingroup$

Leaving GPIO pins as tri-stated inputs have many undesirable effects:



  1. As manufacturing process has certain variance and a lot of other circuitry is connected to GPIO (as output buffer and ESD protection), direction of resulting parasitic leakage is unpredictable, so the state can take either logic high or low;


  2. Again, due to process variation and temperature dependence, the pin leakage can be very small, resulting in either very slow change of logic state after, say, several minutes, which might be a challenge to accommodate in code, or it can drift in unpredictable direction.


  3. Leaving pins floating might lead to establishing some middle potential, where the pin input buffer may act as linear amplifier with substantial gain, causing either self-oscillations (due to parasitic positive feedback across power rails), or be susceptible to external electromagnetic interference. Oscillations can be somewhere internally, and lead to out-of range power consumption.


4... must forget something else... power-on transients?






share|improve this answer









$endgroup$












    Your Answer





    StackExchange.ifUsing("editor", function ()
    return StackExchange.using("mathjaxEditing", function ()
    StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
    StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
    );
    );
    , "mathjax-editing");

    StackExchange.ifUsing("editor", function ()
    return StackExchange.using("schematics", function ()
    StackExchange.schematics.init();
    );
    , "cicuitlab");

    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "135"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f427888%2freasons-for-having-mcu-pin-states-default-to-pull-up-down-out-of-reset%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    5 Answers
    5






    active

    oldest

    votes








    5 Answers
    5






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    8












    $begingroup$

    Because it's good practice to never leave logic pins purely floating.
    Brief TI Overview
    Detailed TI overview
    Amusing dramatized war story of a real-world example






    share|improve this answer









    $endgroup$












    • $begingroup$
      I completely agree. Floating pins are indeed a bad thing for power consumption. But any well behaved firmware should set all unused pins to a known state, so the power loss would only occur coming out of a reset (and this loss can be eliminated by placing external pulls). So is the idea that by giving a default state to a pin (pull-up/down) the FW needs less massaging to get lower power numbers?
      $endgroup$
      – TRISAbits
      21 hours ago






    • 1




      $begingroup$
      I think you've cut to the heart of the matter here. If the firmware is well-behaved and/or the hardware designer had the good sense to apply proper pull-ups or pull-downs, then there would be absolutely no need for this type of initialization. And I'd guess that's why not all chip designers do this. It's all a matter of philosophy -- do you want to presume your users are smart enough to do The Right Thing, or do you want to protect them if they don't? It could be argued either way...
      $endgroup$
      – Mr. Snrub
      21 hours ago










    • $begingroup$
      Certain MCUs have their digital input buffer logic disabled coming out of reset (e.g. PIC12/16/18), which presumably is intended to prevent leakages caused by shoot-through? If so, that would be an alternative to forcing pins in a certain known-state.
      $endgroup$
      – TRISAbits
      11 hours ago






    • 1




      $begingroup$
      BTW, you mentioned leakage currents, but as illustrated in the "amusing dramatized war story", my bigger worry would be oscillations. Leakage currents will go away once the FW sets the pin to a good state, but if a floating pin oscillates then there is the danger of it causing the logic to go into an invalid state.
      $endgroup$
      – Mr. Snrub
      8 hours ago






    • 1




      $begingroup$
      I really mean to say that oscillation on an input pin at any time, whether in reset or not, is probably Bad News. Yes if the oscillation occurred during the reset process, then I would be gravely concerned that the reset process may not fully initialize things to a known good state.
      $endgroup$
      – Mr. Snrub
      7 hours ago















    8












    $begingroup$

    Because it's good practice to never leave logic pins purely floating.
    Brief TI Overview
    Detailed TI overview
    Amusing dramatized war story of a real-world example






    share|improve this answer









    $endgroup$












    • $begingroup$
      I completely agree. Floating pins are indeed a bad thing for power consumption. But any well behaved firmware should set all unused pins to a known state, so the power loss would only occur coming out of a reset (and this loss can be eliminated by placing external pulls). So is the idea that by giving a default state to a pin (pull-up/down) the FW needs less massaging to get lower power numbers?
      $endgroup$
      – TRISAbits
      21 hours ago






    • 1




      $begingroup$
      I think you've cut to the heart of the matter here. If the firmware is well-behaved and/or the hardware designer had the good sense to apply proper pull-ups or pull-downs, then there would be absolutely no need for this type of initialization. And I'd guess that's why not all chip designers do this. It's all a matter of philosophy -- do you want to presume your users are smart enough to do The Right Thing, or do you want to protect them if they don't? It could be argued either way...
      $endgroup$
      – Mr. Snrub
      21 hours ago










    • $begingroup$
      Certain MCUs have their digital input buffer logic disabled coming out of reset (e.g. PIC12/16/18), which presumably is intended to prevent leakages caused by shoot-through? If so, that would be an alternative to forcing pins in a certain known-state.
      $endgroup$
      – TRISAbits
      11 hours ago






    • 1




      $begingroup$
      BTW, you mentioned leakage currents, but as illustrated in the "amusing dramatized war story", my bigger worry would be oscillations. Leakage currents will go away once the FW sets the pin to a good state, but if a floating pin oscillates then there is the danger of it causing the logic to go into an invalid state.
      $endgroup$
      – Mr. Snrub
      8 hours ago






    • 1




      $begingroup$
      I really mean to say that oscillation on an input pin at any time, whether in reset or not, is probably Bad News. Yes if the oscillation occurred during the reset process, then I would be gravely concerned that the reset process may not fully initialize things to a known good state.
      $endgroup$
      – Mr. Snrub
      7 hours ago













    8












    8








    8





    $begingroup$

    Because it's good practice to never leave logic pins purely floating.
    Brief TI Overview
    Detailed TI overview
    Amusing dramatized war story of a real-world example






    share|improve this answer









    $endgroup$



    Because it's good practice to never leave logic pins purely floating.
    Brief TI Overview
    Detailed TI overview
    Amusing dramatized war story of a real-world example







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered 21 hours ago









    Mr. SnrubMr. Snrub

    7205




    7205











    • $begingroup$
      I completely agree. Floating pins are indeed a bad thing for power consumption. But any well behaved firmware should set all unused pins to a known state, so the power loss would only occur coming out of a reset (and this loss can be eliminated by placing external pulls). So is the idea that by giving a default state to a pin (pull-up/down) the FW needs less massaging to get lower power numbers?
      $endgroup$
      – TRISAbits
      21 hours ago






    • 1




      $begingroup$
      I think you've cut to the heart of the matter here. If the firmware is well-behaved and/or the hardware designer had the good sense to apply proper pull-ups or pull-downs, then there would be absolutely no need for this type of initialization. And I'd guess that's why not all chip designers do this. It's all a matter of philosophy -- do you want to presume your users are smart enough to do The Right Thing, or do you want to protect them if they don't? It could be argued either way...
      $endgroup$
      – Mr. Snrub
      21 hours ago










    • $begingroup$
      Certain MCUs have their digital input buffer logic disabled coming out of reset (e.g. PIC12/16/18), which presumably is intended to prevent leakages caused by shoot-through? If so, that would be an alternative to forcing pins in a certain known-state.
      $endgroup$
      – TRISAbits
      11 hours ago






    • 1




      $begingroup$
      BTW, you mentioned leakage currents, but as illustrated in the "amusing dramatized war story", my bigger worry would be oscillations. Leakage currents will go away once the FW sets the pin to a good state, but if a floating pin oscillates then there is the danger of it causing the logic to go into an invalid state.
      $endgroup$
      – Mr. Snrub
      8 hours ago






    • 1




      $begingroup$
      I really mean to say that oscillation on an input pin at any time, whether in reset or not, is probably Bad News. Yes if the oscillation occurred during the reset process, then I would be gravely concerned that the reset process may not fully initialize things to a known good state.
      $endgroup$
      – Mr. Snrub
      7 hours ago
















    • $begingroup$
      I completely agree. Floating pins are indeed a bad thing for power consumption. But any well behaved firmware should set all unused pins to a known state, so the power loss would only occur coming out of a reset (and this loss can be eliminated by placing external pulls). So is the idea that by giving a default state to a pin (pull-up/down) the FW needs less massaging to get lower power numbers?
      $endgroup$
      – TRISAbits
      21 hours ago






    • 1




      $begingroup$
      I think you've cut to the heart of the matter here. If the firmware is well-behaved and/or the hardware designer had the good sense to apply proper pull-ups or pull-downs, then there would be absolutely no need for this type of initialization. And I'd guess that's why not all chip designers do this. It's all a matter of philosophy -- do you want to presume your users are smart enough to do The Right Thing, or do you want to protect them if they don't? It could be argued either way...
      $endgroup$
      – Mr. Snrub
      21 hours ago










    • $begingroup$
      Certain MCUs have their digital input buffer logic disabled coming out of reset (e.g. PIC12/16/18), which presumably is intended to prevent leakages caused by shoot-through? If so, that would be an alternative to forcing pins in a certain known-state.
      $endgroup$
      – TRISAbits
      11 hours ago






    • 1




      $begingroup$
      BTW, you mentioned leakage currents, but as illustrated in the "amusing dramatized war story", my bigger worry would be oscillations. Leakage currents will go away once the FW sets the pin to a good state, but if a floating pin oscillates then there is the danger of it causing the logic to go into an invalid state.
      $endgroup$
      – Mr. Snrub
      8 hours ago






    • 1




      $begingroup$
      I really mean to say that oscillation on an input pin at any time, whether in reset or not, is probably Bad News. Yes if the oscillation occurred during the reset process, then I would be gravely concerned that the reset process may not fully initialize things to a known good state.
      $endgroup$
      – Mr. Snrub
      7 hours ago















    $begingroup$
    I completely agree. Floating pins are indeed a bad thing for power consumption. But any well behaved firmware should set all unused pins to a known state, so the power loss would only occur coming out of a reset (and this loss can be eliminated by placing external pulls). So is the idea that by giving a default state to a pin (pull-up/down) the FW needs less massaging to get lower power numbers?
    $endgroup$
    – TRISAbits
    21 hours ago




    $begingroup$
    I completely agree. Floating pins are indeed a bad thing for power consumption. But any well behaved firmware should set all unused pins to a known state, so the power loss would only occur coming out of a reset (and this loss can be eliminated by placing external pulls). So is the idea that by giving a default state to a pin (pull-up/down) the FW needs less massaging to get lower power numbers?
    $endgroup$
    – TRISAbits
    21 hours ago




    1




    1




    $begingroup$
    I think you've cut to the heart of the matter here. If the firmware is well-behaved and/or the hardware designer had the good sense to apply proper pull-ups or pull-downs, then there would be absolutely no need for this type of initialization. And I'd guess that's why not all chip designers do this. It's all a matter of philosophy -- do you want to presume your users are smart enough to do The Right Thing, or do you want to protect them if they don't? It could be argued either way...
    $endgroup$
    – Mr. Snrub
    21 hours ago




    $begingroup$
    I think you've cut to the heart of the matter here. If the firmware is well-behaved and/or the hardware designer had the good sense to apply proper pull-ups or pull-downs, then there would be absolutely no need for this type of initialization. And I'd guess that's why not all chip designers do this. It's all a matter of philosophy -- do you want to presume your users are smart enough to do The Right Thing, or do you want to protect them if they don't? It could be argued either way...
    $endgroup$
    – Mr. Snrub
    21 hours ago












    $begingroup$
    Certain MCUs have their digital input buffer logic disabled coming out of reset (e.g. PIC12/16/18), which presumably is intended to prevent leakages caused by shoot-through? If so, that would be an alternative to forcing pins in a certain known-state.
    $endgroup$
    – TRISAbits
    11 hours ago




    $begingroup$
    Certain MCUs have their digital input buffer logic disabled coming out of reset (e.g. PIC12/16/18), which presumably is intended to prevent leakages caused by shoot-through? If so, that would be an alternative to forcing pins in a certain known-state.
    $endgroup$
    – TRISAbits
    11 hours ago




    1




    1




    $begingroup$
    BTW, you mentioned leakage currents, but as illustrated in the "amusing dramatized war story", my bigger worry would be oscillations. Leakage currents will go away once the FW sets the pin to a good state, but if a floating pin oscillates then there is the danger of it causing the logic to go into an invalid state.
    $endgroup$
    – Mr. Snrub
    8 hours ago




    $begingroup$
    BTW, you mentioned leakage currents, but as illustrated in the "amusing dramatized war story", my bigger worry would be oscillations. Leakage currents will go away once the FW sets the pin to a good state, but if a floating pin oscillates then there is the danger of it causing the logic to go into an invalid state.
    $endgroup$
    – Mr. Snrub
    8 hours ago




    1




    1




    $begingroup$
    I really mean to say that oscillation on an input pin at any time, whether in reset or not, is probably Bad News. Yes if the oscillation occurred during the reset process, then I would be gravely concerned that the reset process may not fully initialize things to a known good state.
    $endgroup$
    – Mr. Snrub
    7 hours ago




    $begingroup$
    I really mean to say that oscillation on an input pin at any time, whether in reset or not, is probably Bad News. Yes if the oscillation occurred during the reset process, then I would be gravely concerned that the reset process may not fully initialize things to a known good state.
    $endgroup$
    – Mr. Snrub
    7 hours ago













    5












    $begingroup$

    Other answers have given general reasons why a chip maker might make the choice to enable pull-ups by default. However, in the specific case of LPC845, there is an additional reason: it has specialized FAst Initialization Memory (FAIM) that can be used to set the state immediately after reset:




    The FAIM contents provide a user-programmable initial configuration for aspects of the
    microcontroller, which take effect immediately after reset, before code begins to run. For
    instance, the standard I/O pads normally come out of reset with the internal pull-ups
    enabled. In some systems this may cause excess current to flow, until software can
    reconfigure the pads. However, by programming the FAIM appropriately, every pad's reset
    configuration can be customized.




    (LPC84x user manual section 4.2)



    Thus they've chosen the safe (from power usage and EMI point of view) default, while allowing more advanced users to customize the setting.






    share|improve this answer









    $endgroup$












    • $begingroup$
      The downside with the FAIM is that it requires an additional programming step to set it up front, which means that your design should survive the incorrect pull-state until the FAIM is updated. Alternatively you can install a stronger external pull to overdrive the default internal setup, but you've now introduced a perpetual power loss through the external pull. I guess you can't have your cake and eat it too.
      $endgroup$
      – TRISAbits
      11 hours ago










    • $begingroup$
      @TRISAbits Yeah. But after all even if it were tristated, you'd need the external pulldown on important pins, and if it is pulling to the default state, the average loss is not so much.
      $endgroup$
      – jpa
      7 hours ago










    • $begingroup$
      The point I was (poorly) making is that the external pull will have to be stronger than otherwise required in order to overdrive the internal pull. If the pins were tri-stated then the pull could be weaker, which would result is less power loss through the external pull.
      $endgroup$
      – TRISAbits
      5 hours ago















    5












    $begingroup$

    Other answers have given general reasons why a chip maker might make the choice to enable pull-ups by default. However, in the specific case of LPC845, there is an additional reason: it has specialized FAst Initialization Memory (FAIM) that can be used to set the state immediately after reset:




    The FAIM contents provide a user-programmable initial configuration for aspects of the
    microcontroller, which take effect immediately after reset, before code begins to run. For
    instance, the standard I/O pads normally come out of reset with the internal pull-ups
    enabled. In some systems this may cause excess current to flow, until software can
    reconfigure the pads. However, by programming the FAIM appropriately, every pad's reset
    configuration can be customized.




    (LPC84x user manual section 4.2)



    Thus they've chosen the safe (from power usage and EMI point of view) default, while allowing more advanced users to customize the setting.






    share|improve this answer









    $endgroup$












    • $begingroup$
      The downside with the FAIM is that it requires an additional programming step to set it up front, which means that your design should survive the incorrect pull-state until the FAIM is updated. Alternatively you can install a stronger external pull to overdrive the default internal setup, but you've now introduced a perpetual power loss through the external pull. I guess you can't have your cake and eat it too.
      $endgroup$
      – TRISAbits
      11 hours ago










    • $begingroup$
      @TRISAbits Yeah. But after all even if it were tristated, you'd need the external pulldown on important pins, and if it is pulling to the default state, the average loss is not so much.
      $endgroup$
      – jpa
      7 hours ago










    • $begingroup$
      The point I was (poorly) making is that the external pull will have to be stronger than otherwise required in order to overdrive the internal pull. If the pins were tri-stated then the pull could be weaker, which would result is less power loss through the external pull.
      $endgroup$
      – TRISAbits
      5 hours ago













    5












    5








    5





    $begingroup$

    Other answers have given general reasons why a chip maker might make the choice to enable pull-ups by default. However, in the specific case of LPC845, there is an additional reason: it has specialized FAst Initialization Memory (FAIM) that can be used to set the state immediately after reset:




    The FAIM contents provide a user-programmable initial configuration for aspects of the
    microcontroller, which take effect immediately after reset, before code begins to run. For
    instance, the standard I/O pads normally come out of reset with the internal pull-ups
    enabled. In some systems this may cause excess current to flow, until software can
    reconfigure the pads. However, by programming the FAIM appropriately, every pad's reset
    configuration can be customized.




    (LPC84x user manual section 4.2)



    Thus they've chosen the safe (from power usage and EMI point of view) default, while allowing more advanced users to customize the setting.






    share|improve this answer









    $endgroup$



    Other answers have given general reasons why a chip maker might make the choice to enable pull-ups by default. However, in the specific case of LPC845, there is an additional reason: it has specialized FAst Initialization Memory (FAIM) that can be used to set the state immediately after reset:




    The FAIM contents provide a user-programmable initial configuration for aspects of the
    microcontroller, which take effect immediately after reset, before code begins to run. For
    instance, the standard I/O pads normally come out of reset with the internal pull-ups
    enabled. In some systems this may cause excess current to flow, until software can
    reconfigure the pads. However, by programming the FAIM appropriately, every pad's reset
    configuration can be customized.




    (LPC84x user manual section 4.2)



    Thus they've chosen the safe (from power usage and EMI point of view) default, while allowing more advanced users to customize the setting.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered 14 hours ago









    jpajpa

    1,536711




    1,536711











    • $begingroup$
      The downside with the FAIM is that it requires an additional programming step to set it up front, which means that your design should survive the incorrect pull-state until the FAIM is updated. Alternatively you can install a stronger external pull to overdrive the default internal setup, but you've now introduced a perpetual power loss through the external pull. I guess you can't have your cake and eat it too.
      $endgroup$
      – TRISAbits
      11 hours ago










    • $begingroup$
      @TRISAbits Yeah. But after all even if it were tristated, you'd need the external pulldown on important pins, and if it is pulling to the default state, the average loss is not so much.
      $endgroup$
      – jpa
      7 hours ago










    • $begingroup$
      The point I was (poorly) making is that the external pull will have to be stronger than otherwise required in order to overdrive the internal pull. If the pins were tri-stated then the pull could be weaker, which would result is less power loss through the external pull.
      $endgroup$
      – TRISAbits
      5 hours ago
















    • $begingroup$
      The downside with the FAIM is that it requires an additional programming step to set it up front, which means that your design should survive the incorrect pull-state until the FAIM is updated. Alternatively you can install a stronger external pull to overdrive the default internal setup, but you've now introduced a perpetual power loss through the external pull. I guess you can't have your cake and eat it too.
      $endgroup$
      – TRISAbits
      11 hours ago










    • $begingroup$
      @TRISAbits Yeah. But after all even if it were tristated, you'd need the external pulldown on important pins, and if it is pulling to the default state, the average loss is not so much.
      $endgroup$
      – jpa
      7 hours ago










    • $begingroup$
      The point I was (poorly) making is that the external pull will have to be stronger than otherwise required in order to overdrive the internal pull. If the pins were tri-stated then the pull could be weaker, which would result is less power loss through the external pull.
      $endgroup$
      – TRISAbits
      5 hours ago















    $begingroup$
    The downside with the FAIM is that it requires an additional programming step to set it up front, which means that your design should survive the incorrect pull-state until the FAIM is updated. Alternatively you can install a stronger external pull to overdrive the default internal setup, but you've now introduced a perpetual power loss through the external pull. I guess you can't have your cake and eat it too.
    $endgroup$
    – TRISAbits
    11 hours ago




    $begingroup$
    The downside with the FAIM is that it requires an additional programming step to set it up front, which means that your design should survive the incorrect pull-state until the FAIM is updated. Alternatively you can install a stronger external pull to overdrive the default internal setup, but you've now introduced a perpetual power loss through the external pull. I guess you can't have your cake and eat it too.
    $endgroup$
    – TRISAbits
    11 hours ago












    $begingroup$
    @TRISAbits Yeah. But after all even if it were tristated, you'd need the external pulldown on important pins, and if it is pulling to the default state, the average loss is not so much.
    $endgroup$
    – jpa
    7 hours ago




    $begingroup$
    @TRISAbits Yeah. But after all even if it were tristated, you'd need the external pulldown on important pins, and if it is pulling to the default state, the average loss is not so much.
    $endgroup$
    – jpa
    7 hours ago












    $begingroup$
    The point I was (poorly) making is that the external pull will have to be stronger than otherwise required in order to overdrive the internal pull. If the pins were tri-stated then the pull could be weaker, which would result is less power loss through the external pull.
    $endgroup$
    – TRISAbits
    5 hours ago




    $begingroup$
    The point I was (poorly) making is that the external pull will have to be stronger than otherwise required in order to overdrive the internal pull. If the pins were tri-stated then the pull could be weaker, which would result is less power loss through the external pull.
    $endgroup$
    – TRISAbits
    5 hours ago











    4












    $begingroup$

    Back in the days there were Intel 8051 microcontrollers that only had open drain I/O pins, so most of the time you needed external pull-ups anyway to do useful things like connecting to pushbuttons or controlling CMOS inputs of other chips. This is most likely to have easy redesign of such boards with a modern microcontroller, or people from that era that are accustomed to designing with pulled-up open-collector I/Os. Back in the day, you mostly needed pull-ups if anything, and rarely pull-downs.






    share|improve this answer









    $endgroup$












    • $begingroup$
      That's a really interesting bit of insight, and explains why a lot of logic chips have active-low output-enable pins. Active-high logic doesn't mesh as well when the default pull-state is high. As an aside it also doesn't mesh well when directly connected to the gate of a NMOS, unless you want the transistor to turn on by default.
      $endgroup$
      – TRISAbits
      11 hours ago






    • 1




      $begingroup$
      Also other chips of that era have active signals when low. TTL chips (74XX and 74LSXX series for example) can pull low stronger than push high. Therefore fast falling edge is sharper and more defined than slow exponentially rising edge. Also small currents flow in and out of chip inputs as they are not so high impedance. Therefore, pull-ups are sometimes necessary, and pull-ups can be weaker than pull-downs, so that's why you have active low logic with pull-ups, with pushbuttons grounding the inputs and outputs turning on LEDs by grounding the LED via resistor.
      $endgroup$
      – Justme
      7 hours ago















    4












    $begingroup$

    Back in the days there were Intel 8051 microcontrollers that only had open drain I/O pins, so most of the time you needed external pull-ups anyway to do useful things like connecting to pushbuttons or controlling CMOS inputs of other chips. This is most likely to have easy redesign of such boards with a modern microcontroller, or people from that era that are accustomed to designing with pulled-up open-collector I/Os. Back in the day, you mostly needed pull-ups if anything, and rarely pull-downs.






    share|improve this answer









    $endgroup$












    • $begingroup$
      That's a really interesting bit of insight, and explains why a lot of logic chips have active-low output-enable pins. Active-high logic doesn't mesh as well when the default pull-state is high. As an aside it also doesn't mesh well when directly connected to the gate of a NMOS, unless you want the transistor to turn on by default.
      $endgroup$
      – TRISAbits
      11 hours ago






    • 1




      $begingroup$
      Also other chips of that era have active signals when low. TTL chips (74XX and 74LSXX series for example) can pull low stronger than push high. Therefore fast falling edge is sharper and more defined than slow exponentially rising edge. Also small currents flow in and out of chip inputs as they are not so high impedance. Therefore, pull-ups are sometimes necessary, and pull-ups can be weaker than pull-downs, so that's why you have active low logic with pull-ups, with pushbuttons grounding the inputs and outputs turning on LEDs by grounding the LED via resistor.
      $endgroup$
      – Justme
      7 hours ago













    4












    4








    4





    $begingroup$

    Back in the days there were Intel 8051 microcontrollers that only had open drain I/O pins, so most of the time you needed external pull-ups anyway to do useful things like connecting to pushbuttons or controlling CMOS inputs of other chips. This is most likely to have easy redesign of such boards with a modern microcontroller, or people from that era that are accustomed to designing with pulled-up open-collector I/Os. Back in the day, you mostly needed pull-ups if anything, and rarely pull-downs.






    share|improve this answer









    $endgroup$



    Back in the days there were Intel 8051 microcontrollers that only had open drain I/O pins, so most of the time you needed external pull-ups anyway to do useful things like connecting to pushbuttons or controlling CMOS inputs of other chips. This is most likely to have easy redesign of such boards with a modern microcontroller, or people from that era that are accustomed to designing with pulled-up open-collector I/Os. Back in the day, you mostly needed pull-ups if anything, and rarely pull-downs.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered 20 hours ago









    JustmeJustme

    1,7921411




    1,7921411











    • $begingroup$
      That's a really interesting bit of insight, and explains why a lot of logic chips have active-low output-enable pins. Active-high logic doesn't mesh as well when the default pull-state is high. As an aside it also doesn't mesh well when directly connected to the gate of a NMOS, unless you want the transistor to turn on by default.
      $endgroup$
      – TRISAbits
      11 hours ago






    • 1




      $begingroup$
      Also other chips of that era have active signals when low. TTL chips (74XX and 74LSXX series for example) can pull low stronger than push high. Therefore fast falling edge is sharper and more defined than slow exponentially rising edge. Also small currents flow in and out of chip inputs as they are not so high impedance. Therefore, pull-ups are sometimes necessary, and pull-ups can be weaker than pull-downs, so that's why you have active low logic with pull-ups, with pushbuttons grounding the inputs and outputs turning on LEDs by grounding the LED via resistor.
      $endgroup$
      – Justme
      7 hours ago
















    • $begingroup$
      That's a really interesting bit of insight, and explains why a lot of logic chips have active-low output-enable pins. Active-high logic doesn't mesh as well when the default pull-state is high. As an aside it also doesn't mesh well when directly connected to the gate of a NMOS, unless you want the transistor to turn on by default.
      $endgroup$
      – TRISAbits
      11 hours ago






    • 1




      $begingroup$
      Also other chips of that era have active signals when low. TTL chips (74XX and 74LSXX series for example) can pull low stronger than push high. Therefore fast falling edge is sharper and more defined than slow exponentially rising edge. Also small currents flow in and out of chip inputs as they are not so high impedance. Therefore, pull-ups are sometimes necessary, and pull-ups can be weaker than pull-downs, so that's why you have active low logic with pull-ups, with pushbuttons grounding the inputs and outputs turning on LEDs by grounding the LED via resistor.
      $endgroup$
      – Justme
      7 hours ago















    $begingroup$
    That's a really interesting bit of insight, and explains why a lot of logic chips have active-low output-enable pins. Active-high logic doesn't mesh as well when the default pull-state is high. As an aside it also doesn't mesh well when directly connected to the gate of a NMOS, unless you want the transistor to turn on by default.
    $endgroup$
    – TRISAbits
    11 hours ago




    $begingroup$
    That's a really interesting bit of insight, and explains why a lot of logic chips have active-low output-enable pins. Active-high logic doesn't mesh as well when the default pull-state is high. As an aside it also doesn't mesh well when directly connected to the gate of a NMOS, unless you want the transistor to turn on by default.
    $endgroup$
    – TRISAbits
    11 hours ago




    1




    1




    $begingroup$
    Also other chips of that era have active signals when low. TTL chips (74XX and 74LSXX series for example) can pull low stronger than push high. Therefore fast falling edge is sharper and more defined than slow exponentially rising edge. Also small currents flow in and out of chip inputs as they are not so high impedance. Therefore, pull-ups are sometimes necessary, and pull-ups can be weaker than pull-downs, so that's why you have active low logic with pull-ups, with pushbuttons grounding the inputs and outputs turning on LEDs by grounding the LED via resistor.
    $endgroup$
    – Justme
    7 hours ago




    $begingroup$
    Also other chips of that era have active signals when low. TTL chips (74XX and 74LSXX series for example) can pull low stronger than push high. Therefore fast falling edge is sharper and more defined than slow exponentially rising edge. Also small currents flow in and out of chip inputs as they are not so high impedance. Therefore, pull-ups are sometimes necessary, and pull-ups can be weaker than pull-downs, so that's why you have active low logic with pull-ups, with pushbuttons grounding the inputs and outputs turning on LEDs by grounding the LED via resistor.
    $endgroup$
    – Justme
    7 hours ago











    3












    $begingroup$

    From a systems point of view, having the pins start in a defined state is a benefit. For example, a motor might be attached that shouldn't be activated without command. Peripherals usually expect their interfaces to be in a certain state, and starting in high-Z may not provide the required state. As the internal pull ups/downs in a typical microcontroller are relatively weak, they may be overridden by a stronger external pull up/down where required. As an additional note, it is nice to see in the datasheet what the expected behaviour of the pins is, this is sometimes not included..!






    share|improve this answer









    $endgroup$








    • 1




      $begingroup$
      The problem with providing an external pull-up when an internal one is enabled is two-fold: [1] The external pull has to be properly sized to be far stronger (good rule of thumb is at least 10x). Otherwise you will create a voltage divider, which can set the voltage into that middle no-mans-land zone. [2] The stronger external pull introduces a continuous power loss (if the pin state is frequently opposite the pull direction), which will quickly consume more power than any loses from having tri-stated pins out of reset.
      $endgroup$
      – TRISAbits
      11 hours ago










    • $begingroup$
      @TRISAbits Agreed on both points. Not that desirable to override, but most internals are 50-100K so not disasterous. Read the manual, as ever :)
      $endgroup$
      – awjlogan
      11 hours ago











    • $begingroup$
      @TRISAbits And also it's not about power in this example, it's about how the wider system interacts at reset, not just the MCU.
      $endgroup$
      – awjlogan
      11 hours ago
















    3












    $begingroup$

    From a systems point of view, having the pins start in a defined state is a benefit. For example, a motor might be attached that shouldn't be activated without command. Peripherals usually expect their interfaces to be in a certain state, and starting in high-Z may not provide the required state. As the internal pull ups/downs in a typical microcontroller are relatively weak, they may be overridden by a stronger external pull up/down where required. As an additional note, it is nice to see in the datasheet what the expected behaviour of the pins is, this is sometimes not included..!






    share|improve this answer









    $endgroup$








    • 1




      $begingroup$
      The problem with providing an external pull-up when an internal one is enabled is two-fold: [1] The external pull has to be properly sized to be far stronger (good rule of thumb is at least 10x). Otherwise you will create a voltage divider, which can set the voltage into that middle no-mans-land zone. [2] The stronger external pull introduces a continuous power loss (if the pin state is frequently opposite the pull direction), which will quickly consume more power than any loses from having tri-stated pins out of reset.
      $endgroup$
      – TRISAbits
      11 hours ago










    • $begingroup$
      @TRISAbits Agreed on both points. Not that desirable to override, but most internals are 50-100K so not disasterous. Read the manual, as ever :)
      $endgroup$
      – awjlogan
      11 hours ago











    • $begingroup$
      @TRISAbits And also it's not about power in this example, it's about how the wider system interacts at reset, not just the MCU.
      $endgroup$
      – awjlogan
      11 hours ago














    3












    3








    3





    $begingroup$

    From a systems point of view, having the pins start in a defined state is a benefit. For example, a motor might be attached that shouldn't be activated without command. Peripherals usually expect their interfaces to be in a certain state, and starting in high-Z may not provide the required state. As the internal pull ups/downs in a typical microcontroller are relatively weak, they may be overridden by a stronger external pull up/down where required. As an additional note, it is nice to see in the datasheet what the expected behaviour of the pins is, this is sometimes not included..!






    share|improve this answer









    $endgroup$



    From a systems point of view, having the pins start in a defined state is a benefit. For example, a motor might be attached that shouldn't be activated without command. Peripherals usually expect their interfaces to be in a certain state, and starting in high-Z may not provide the required state. As the internal pull ups/downs in a typical microcontroller are relatively weak, they may be overridden by a stronger external pull up/down where required. As an additional note, it is nice to see in the datasheet what the expected behaviour of the pins is, this is sometimes not included..!







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered 16 hours ago









    awjloganawjlogan

    3,79911328




    3,79911328







    • 1




      $begingroup$
      The problem with providing an external pull-up when an internal one is enabled is two-fold: [1] The external pull has to be properly sized to be far stronger (good rule of thumb is at least 10x). Otherwise you will create a voltage divider, which can set the voltage into that middle no-mans-land zone. [2] The stronger external pull introduces a continuous power loss (if the pin state is frequently opposite the pull direction), which will quickly consume more power than any loses from having tri-stated pins out of reset.
      $endgroup$
      – TRISAbits
      11 hours ago










    • $begingroup$
      @TRISAbits Agreed on both points. Not that desirable to override, but most internals are 50-100K so not disasterous. Read the manual, as ever :)
      $endgroup$
      – awjlogan
      11 hours ago











    • $begingroup$
      @TRISAbits And also it's not about power in this example, it's about how the wider system interacts at reset, not just the MCU.
      $endgroup$
      – awjlogan
      11 hours ago













    • 1




      $begingroup$
      The problem with providing an external pull-up when an internal one is enabled is two-fold: [1] The external pull has to be properly sized to be far stronger (good rule of thumb is at least 10x). Otherwise you will create a voltage divider, which can set the voltage into that middle no-mans-land zone. [2] The stronger external pull introduces a continuous power loss (if the pin state is frequently opposite the pull direction), which will quickly consume more power than any loses from having tri-stated pins out of reset.
      $endgroup$
      – TRISAbits
      11 hours ago










    • $begingroup$
      @TRISAbits Agreed on both points. Not that desirable to override, but most internals are 50-100K so not disasterous. Read the manual, as ever :)
      $endgroup$
      – awjlogan
      11 hours ago











    • $begingroup$
      @TRISAbits And also it's not about power in this example, it's about how the wider system interacts at reset, not just the MCU.
      $endgroup$
      – awjlogan
      11 hours ago








    1




    1




    $begingroup$
    The problem with providing an external pull-up when an internal one is enabled is two-fold: [1] The external pull has to be properly sized to be far stronger (good rule of thumb is at least 10x). Otherwise you will create a voltage divider, which can set the voltage into that middle no-mans-land zone. [2] The stronger external pull introduces a continuous power loss (if the pin state is frequently opposite the pull direction), which will quickly consume more power than any loses from having tri-stated pins out of reset.
    $endgroup$
    – TRISAbits
    11 hours ago




    $begingroup$
    The problem with providing an external pull-up when an internal one is enabled is two-fold: [1] The external pull has to be properly sized to be far stronger (good rule of thumb is at least 10x). Otherwise you will create a voltage divider, which can set the voltage into that middle no-mans-land zone. [2] The stronger external pull introduces a continuous power loss (if the pin state is frequently opposite the pull direction), which will quickly consume more power than any loses from having tri-stated pins out of reset.
    $endgroup$
    – TRISAbits
    11 hours ago












    $begingroup$
    @TRISAbits Agreed on both points. Not that desirable to override, but most internals are 50-100K so not disasterous. Read the manual, as ever :)
    $endgroup$
    – awjlogan
    11 hours ago





    $begingroup$
    @TRISAbits Agreed on both points. Not that desirable to override, but most internals are 50-100K so not disasterous. Read the manual, as ever :)
    $endgroup$
    – awjlogan
    11 hours ago













    $begingroup$
    @TRISAbits And also it's not about power in this example, it's about how the wider system interacts at reset, not just the MCU.
    $endgroup$
    – awjlogan
    11 hours ago





    $begingroup$
    @TRISAbits And also it's not about power in this example, it's about how the wider system interacts at reset, not just the MCU.
    $endgroup$
    – awjlogan
    11 hours ago












    2












    $begingroup$

    Leaving GPIO pins as tri-stated inputs have many undesirable effects:



    1. As manufacturing process has certain variance and a lot of other circuitry is connected to GPIO (as output buffer and ESD protection), direction of resulting parasitic leakage is unpredictable, so the state can take either logic high or low;


    2. Again, due to process variation and temperature dependence, the pin leakage can be very small, resulting in either very slow change of logic state after, say, several minutes, which might be a challenge to accommodate in code, or it can drift in unpredictable direction.


    3. Leaving pins floating might lead to establishing some middle potential, where the pin input buffer may act as linear amplifier with substantial gain, causing either self-oscillations (due to parasitic positive feedback across power rails), or be susceptible to external electromagnetic interference. Oscillations can be somewhere internally, and lead to out-of range power consumption.


    4... must forget something else... power-on transients?






    share|improve this answer









    $endgroup$

















      2












      $begingroup$

      Leaving GPIO pins as tri-stated inputs have many undesirable effects:



      1. As manufacturing process has certain variance and a lot of other circuitry is connected to GPIO (as output buffer and ESD protection), direction of resulting parasitic leakage is unpredictable, so the state can take either logic high or low;


      2. Again, due to process variation and temperature dependence, the pin leakage can be very small, resulting in either very slow change of logic state after, say, several minutes, which might be a challenge to accommodate in code, or it can drift in unpredictable direction.


      3. Leaving pins floating might lead to establishing some middle potential, where the pin input buffer may act as linear amplifier with substantial gain, causing either self-oscillations (due to parasitic positive feedback across power rails), or be susceptible to external electromagnetic interference. Oscillations can be somewhere internally, and lead to out-of range power consumption.


      4... must forget something else... power-on transients?






      share|improve this answer









      $endgroup$















        2












        2








        2





        $begingroup$

        Leaving GPIO pins as tri-stated inputs have many undesirable effects:



        1. As manufacturing process has certain variance and a lot of other circuitry is connected to GPIO (as output buffer and ESD protection), direction of resulting parasitic leakage is unpredictable, so the state can take either logic high or low;


        2. Again, due to process variation and temperature dependence, the pin leakage can be very small, resulting in either very slow change of logic state after, say, several minutes, which might be a challenge to accommodate in code, or it can drift in unpredictable direction.


        3. Leaving pins floating might lead to establishing some middle potential, where the pin input buffer may act as linear amplifier with substantial gain, causing either self-oscillations (due to parasitic positive feedback across power rails), or be susceptible to external electromagnetic interference. Oscillations can be somewhere internally, and lead to out-of range power consumption.


        4... must forget something else... power-on transients?






        share|improve this answer









        $endgroup$



        Leaving GPIO pins as tri-stated inputs have many undesirable effects:



        1. As manufacturing process has certain variance and a lot of other circuitry is connected to GPIO (as output buffer and ESD protection), direction of resulting parasitic leakage is unpredictable, so the state can take either logic high or low;


        2. Again, due to process variation and temperature dependence, the pin leakage can be very small, resulting in either very slow change of logic state after, say, several minutes, which might be a challenge to accommodate in code, or it can drift in unpredictable direction.


        3. Leaving pins floating might lead to establishing some middle potential, where the pin input buffer may act as linear amplifier with substantial gain, causing either self-oscillations (due to parasitic positive feedback across power rails), or be susceptible to external electromagnetic interference. Oscillations can be somewhere internally, and lead to out-of range power consumption.


        4... must forget something else... power-on transients?







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 21 hours ago









        Ale..chenskiAle..chenski

        28.4k11866




        28.4k11866



























            draft saved

            draft discarded
















































            Thanks for contributing an answer to Electrical Engineering Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            Use MathJax to format equations. MathJax reference.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f427888%2freasons-for-having-mcu-pin-states-default-to-pull-up-down-out-of-reset%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            getting Checkpoint VPN SSL Network Extender working in the command lineHow to connect to CheckPoint VPN on Ubuntu 18.04LTS?Will the Linux ( red-hat ) Open VPNC Client connect to checkpoint or nortel VPN gateways?VPN client for linux machine + support checkpoint gatewayVPN SSL Network Extender in FirefoxLinux Checkpoint SNX tool configuration issuesCheck Point - Connect under Linux - snx + OTPSNX VPN Ububuntu 18.XXUsing Checkpoint VPN SSL Network Extender CLI with certificateVPN with network manager (nm-applet) is not workingWill the Linux ( red-hat ) Open VPNC Client connect to checkpoint or nortel VPN gateways?VPN client for linux machine + support checkpoint gatewayImport VPN config files to NetworkManager from command lineTrouble connecting to VPN using network-manager, while command line worksStart a VPN connection with PPTP protocol on command linestarting a docker service daemon breaks the vpn networkCan't connect to vpn with Network-managerVPN SSL Network Extender in FirefoxUsing Checkpoint VPN SSL Network Extender CLI with certificate

            Cannot Extend partition with GParted The 2019 Stack Overflow Developer Survey Results Are In Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern) 2019 Community Moderator Election ResultsCan't increase partition size with GParted?GParted doesn't recognize the unallocated space after my current partitionWhat is the best way to add unallocated space located before to Ubuntu 12.04 partition with GParted live?I can't figure out how to extend my Arch home partition into free spaceGparted Linux Mint 18.1 issueTrying to extend but swap partition is showing as Unknown in Gparted, shows proper from fdiskRearrange partitions in gparted to extend a partitionUnable to extend partition even though unallocated space is next to it using GPartedAllocate free space to root partitiongparted: how to merge unallocated space with a partition

            Marilyn Monroe Ny fiainany manokana | Jereo koa | Meny fitetezanafanitarana azy.