HackMD
Microcontroller GPIOs during and after reset
Microcontrollers these days are fast and well-equipped for brushless motor applications and power inverters, thanks to multiple >1 MSps A/D converters, fast processing with FPU support and GPIO.
As such, they can be put directly between voltage / current sensing circuitry and gate driver inputs.
There's only one thing that needs to be prevented at all cost: The microcontroller must not lock up during operation or trigger a reset.
The one thing one doesn't want to see is a power stage built for pulsed operation getting stuck with FETs turned on for several hundred milliseconds:
Shown above is the reaction of an Atmel (now Microchip) SAME70Q21 to a hardware reset observed during reconfiguration of an existing piece of hardware, with the corresponding I/Os now dedicated to controlling a 2kA MOSFET H-bridge.
Such a glitch is wholly unacceptable, but what causes it?
Exploring the Problem
Due to assembly issues, the board ended up with solder bridges behind the 0.5mm pitch LQFP pins, which went unnoticed and caused excessive current draw. Such conditions must be noted down, as they can likely cause degradation or destruction of the peripheral circuity.
After reworking, the controller seemed to work fine, so let's assume it did not suffer obvious damage.
- Pushing the reset button multiple times shows it can be generated consistently.
- Keeping the button pressed causes the level to be stuck high → it's part of the reset state, not firmware-related (yet might still be subject to fuse settings if present).
- 270 kOhm load does not cause a big voltage drop, so it's not just leakage.
- 33 kOhm load results in a voltage drop from 3.2V to 0.9V -> approx. 84 kOhm source resistance → in line with internal pull-up values.
Something is up. Let's check the register defaults for a set of GPIOs.
Datasheet Specifications
SAME70 family datasheet: SAM-E70-S70-V70-V71-Family-Data-Sheet
The SAME70 PIO logic for most I/Os contains the upper half of Figure 32-2 below. Hidden logic prevents PU and PD form being active at the same time (reset before set), and it's worth noting that…
reading a one in PIO_PUSR means the pullup is disabled
and reading a zero means the pullup is enabled.
PIO_PUSR resetting to 0x000000000 would thus mean pull-ups are active after reset.
The PIO section and 32.6.23 PIO Pull-Up Status Register do not harbor any specific information about PUSR during and right after reset, before the clock initialization has waited for the PLL to lock and so on.
The Reset State information is ultimately given in the last column of the pin capabilities tables under Package and Pinout. It turns out that basically ALL I/Os are reset to PIO, Input (I), Schmitt trigger (ST), and indeed Pull-Up (PU) active.
Well, drat. And there does not seem to be a way to configure them to be PD upon reset.
Looking for Answers
Another unsuspecting victim has run into the same unexpected reset behavior already (see thread on Stackexchange/cached version).
In said situation, they were looking at LPC845:
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).
What follows is an effort to find answers (or rather explanations to make the world make sense). In the special case of LPC845, the behavior can actually be changed:
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.
SAME70 on the other hand does have Schmitt trigger inputs which would cause additional dissipation when just left floating, but that's once more a matter of a short interval during and after reset, or a matter of which registers are maintained in powered-down states. At any rate, a claim that PU/PD would be mandatory due to EMI issues need to be justified against the ability to be able to hook up any GPIO to a data bus without impacting its stability to reset behavior.
Devices With Hi-Z State GPIOs
In contrast, ATTiny / ATMega microcontrollers as well as STM32 (STM32H755ZI datasheet cited anecdotally below) ought to have floating GPIOs, leaving it up to the designer to add external ~100 kOhm pull-down resistors to ensure well-defined voltages during reset, without having to fight internal pull-ups with much lower resistor values (~10 kOhm to overcome SAME70 internal PU resistors and establish < 0.4V/0.8V for an LVCMOS33 "low").
Unless otherwise specified by a note, all I/Os
are set as floating inputs during and after reset.
When merely driving optocouplers, a 50 .. 150 kOhm pull-up resistor may go unnoticed since the current transfer ratio (CTR) or detection circuit threshold will prevent a false activation, but it's best not to rely on the exact resistance value (on the semiconductor level it's a poorly controlled parameter and may change over temperature, see SE thread/chached version).
Takeaways
Configuration tools may not necessarily indicate whether a GPIO has a pull-up, pull-down or high impedance during and right after reset.
The behavior cannot be assumed based on the product category or vendor, but the information is also not front and center in the datasheet.
It appears to be merely a side note at times, unless they're being fancy and need to advertise some form of advanced GPIO functionality.
