Skip to main content
craig
craig
Associate III
September 21, 2015
Question

STM32F4 GPIO Reset Values

  • September 21, 2015
  • 6 replies
  • 4032 views
Posted on September 21, 2015 at 18:53

I have an issue that seems to be related to some fundamental lack of understanding about GPIO behavior that I can't figure out.  The most clear symptom I have identified is this:

I'm working with an STM32F405RGT6 and have PC5 driving an enable pin on a regulator that powers some accessories (not the MCU itself).  That enable pin is pulled low with an external 10k and driven high by the MCU during normal operation.  The intent is that any time the MCU enters a standby or reset condition that the regulator gets disabled by 10k pull-down thereby powering off all of the accessories as well.

This strategy (good one?) has been working well when putting the MCU in standby.  However, when enabling the IWDG today for the first time I've noticed that an MCU reset leaves the GPIO (PC5) configured after the reset so the accessory's regulator is never power cycled as I want.  In fact, all relevant registers remain configured and don't go back to their expected ''reset'' values.

STM32F4 reference manual RM0090 section 8.4.1 states that the MODER reset values for port C are 0x0000 0000 (input).  Doesn't this mean that following a IWDG reset that the MCU should start up with PC5 (and all other port C pins) in input mode?  Instead I'm observing through my debugger (verified with scope) that PC5 is still configured exactly the same with execution paused immediately after reset as it is during normal operation -- driven high by the MCU and the regulator remains enabled.

Relevant registers are below:

MODER5 0x1

OTYPER5 0x0

OSPEEDR5 0x0

PUPDR5 0x0

IDR5 0x1

ODR5 0x1
    This topic has been closed for replies.

    6 replies

    Tesla DeLorean
    Tesla DeLorean
    Guru
    September 21, 2015
    Posted on September 21, 2015 at 19:02

    Do you have an external driver on NRST?

    If you disconnect the debugger, and you report the GPIO configurations via a serial port, what does the setting look like after a reset?

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    craig
    craigAuthor
    Associate III
    September 21, 2015
    Posted on September 21, 2015 at 19:14

    NRST is pulled high via 10k and a 0.1uF cap to ground.  There's a micro-switch to pull the line low manually which does work as expected.  When pressed the part resets, PC5 floats, and the regulator gets disabled from the external 10k pull-down on that line.  This aspect of the design as been stable/fine for quite some time just like putting the part in standby.

    I haven't tried disconnecting the debugger.  I had assumed that the reset values for GPIO were hardware-induced so debugging wouldn't have an impact.  Unfortunately I'm very late in this design with no access to a USART and an incredibly tight PCB layout so I'll have to get creative to try to see those register values on reset without a debugger.  Perhaps just experimenting with a spare Discovery board might be easier.

    Can you confirm that it's supposed to work the way I've intended?  In other words, all GPIOs' configs should be set to their documented reset values even upon IWDG reset?  I'm happy to keep experimenting as long as I'm on the right track and something's just amiss.
    Tesla DeLorean
    Tesla DeLorean
    Guru
    September 21, 2015
    Posted on September 21, 2015 at 23:04

    I'm not aware of any errata relating to IWDG and PC5, my expectation is that a reset will clear the registers as described in the reference manual.

    Problems often arise when people actively drive the NRST pin high, as the pin is bidirectional, and this interferes with the chip's ability to reset correctly.

    Getting a USART output either via a test point, or edge castallation, is definitely something I'd recommend in all designs. The debugger is usually more invasive than people thing.

    Look very carefully about what's going on in your Reset code path, most specifically the SystemInit() and things it calls, dependencies on the pre-initialization state of C code (statics), and any code that initializes pins/peripherals.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    craig
    craigAuthor
    Associate III
    September 21, 2015
    Posted on September 21, 2015 at 23:05

    Thanks for your help clive1.  As a follow-up to anyone that might find this later:

    The port's configuration is indeed being set back to the documented defaults in reference manual RM0090 section 8.4.1 after an IWDG reset the same as when the part is reset from a NRST edge or similar.  It appears that something is a bit broken in my debugger (Crossworks for ARM) potentially with the way they put a loader in SRAM for debug builds and read/transmit registers after a reset.

    Something is broken in my debugger and I got worried that I didn't have a good understanding but the part is behaving as one would expect.  To determine the issue I simply monitored the ODR register on boot and made a 5 second delay if the part booted with ODR != 0.  It boots with ODR==0 every time (as documented) no matter the reset source even though my debugger might be a liar.
    craig
    craigAuthor
    Associate III
    September 21, 2015
    Posted on September 21, 2015 at 23:09

    > Problems often arise when people actively drive the NRSTpin high, as the pin is bidirectional, and this interferes with thechip's ability to reset correctly.

    WHOA!  Can you reference somewhere I can read more about this?  I thought my implementation of NRST was correct and common.  I'm 100% self taught and work by myself in a vacuum.  Although I've determined my issue I'd still love to learn more in case I've overlooked something significant with NRST.
    Tesla DeLorean
    Tesla DeLorean
    Guru
    September 21, 2015
    Posted on September 22, 2015 at 00:33

    Your pull-up scheme is fine. I tend to prefer having supply thresholding POR circuits, but the STM32 has it's own.

    No, my point is if someone uses a push-pull driver to set NRST high (ie off an FPGA or other CPU GPIO pin), the chip can't over come this with it's internal reset circuit, and that malfunctions. The NRST should be driven low by an open-drain, as many devices can generate a reset.

    One variant of this issue is things like NVIC_SystemReset() get stuck in a while() loop, or watchdogs fail to do their job as expected. It's a very common issue when migrating to ARM devices.

    The other classic failure is that the STM32 can reset everything else on your board sharing the NRST/NRESET net. The thing that usually catches people are the supply thresholds, where the supply browns out, and bang the reset clamps for many milliseconds. This tends to be most surprising to people using RC reset circuits, as they migrate to POR circuits with laser trimmed threshold devices, that clamp for 100ms, this highlights issues with under designed power supply/regulation, or slow rise on supplies. Other ARM devices can get very complicated, with 3 different supply rails, and rules on ordering startup sequences.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Terms & ConditionsAccessibility statement