STM32 GPIOs state during/after startup

dw_2fast4u85 · ‎2015-10-12

Posted on October 12, 2015 at 11:25

Hi guys,

as a preface: Thank you to everybody contributing in these forums! I have found a lot of useful information and good ideas here.

Here comes my question:

I work with the STM32F100VB. In my application it's vital that the pins of the STM32 are in well-defined states during and after startup (reset). In the reference manual you can read the following:

7.1.1 General-purpose I/O (GPIO)

During and just after reset, the alternate functions are not active and the I/O ports are

configured in Input Floating mode (CNFx[1:0]=01b, MODEx[1:0]=00b).

Now... what's the right procedure to activate the clock, setup the IO pins and define the desired output potential to the pins? In which order should it be done?

I found that if I set up the clock first, activate the clock for the GPIO ports and then do the GPIO setup itself, I see (undesired) spikes at the output pin under certain conditions.

What I essentially want:

- Pin is in ''input floating'' mode and held high via external pullup during reset

- ''Gapless'' transition of the pin being input floating (external pullup) to the pin being output with voltage ''high''.

Any recommendations?

Thank you so much.

BR,

Dan.

ferrarofcf · ‎2015-10-12

Posted on October 12, 2015 at 11:53

try using

GPIO_SetBits(...);

GPIO_ResetBits(...);

before of

GPIO_Init(...);

dw_2fast4u85 · ‎2015-10-12

Posted on October 12, 2015 at 14:20

I think that's what I'm doing, though I use another syntax.

When should I activate the clock for the GPIOs?

RCC->APB2ENR |= (RCC_APB2ENR_IOPAEN | RCC_APB2ENR_IOPBEN | ...);

Will the STM ''forget'' the config I write if the clock is turned off at that time? Or, respectively, if I turn on the clock before doing the GPIO config, how can I avoid that spike on the pin?

Pin is ''high'' (input floating, external pull-up) -> activate clock -> configure pin as ''output'' -> pin goes low (output push-pull) -> pin goes high again (after a few cycles?).

Code in short:

// activate clock for GPIO A

RCC->APB2ENR |= RCC_APB2ENR_IOPAEN;

// output push-pull (2 MHz)

uint16_t tmpcrl = GPIO_CRL_MODE0_1;

// pin should be ''high'' (of course, I use defines instead of ''0x01'')

GPIOA->BSRR |= 0x01;

// write config

GPIOA->CRL = tmpcrl;

I can work around this problem, but I'm still interested how I can make sure that the pin stays ''high'' during configuration (from input floating/ext. pull-up to output push-pull, state ''high''), independent of the time it takes for the code to be executed.

waclawek.jan · ‎2015-10-12

Posted on October 12, 2015 at 20:17

> GPIOA->BSRR |= 0x01;

No - BSRR is write only. Should make no harm, though.

What I'd try is to read back ODR after writing to BSRR and before writing to CRL.

JW

dw_2fast4u85 · ‎2015-10-13

Posted on October 13, 2015 at 14:08

I don't understand your comment, of course BSRR is write-only, but that's what I'm doing! I want to make sure the corresponding pin is ''high'' as soon as it transitions to being an output.

Good idea with the ODR. I'm only setting it but not checking, that's probably worth a try!

Thanks :)

waclawek.jan · ‎2015-10-13

Posted on October 13, 2015 at 19:37

> I don't understand your comment, of course BSRR is write-only, but that's what I'm doing!

No, you use the |= operator, which performs a read, the OR, and then the write.

> I want to make sure the corresponding pin is ''high'' as soon as it transitions to being an output.

You want to make sure it is ''high'' *before* outputs are switched on. This is why you should read back ODR. There should be no need to check, it is just to make sure the internal process of setting the pin (which in itself is most probably a read-modify-write but this time on the hardware level directly in the GPIO hardware). That is, unless there's some fatal error in the hardware and it does not hold the promise of atomicity - but honestly, I wouldn't be surprised.

JW

dw_2fast4u85 · ‎2015-10-15

Posted on October 15, 2015 at 10:22

That was very helpful - thanks a lot! :)