spike on a GPIO pin on power ON

yafisdamda · ‎2015-11-10

Posted on November 11, 2015 at 08:35

Hi STM32 forum.

I am working on a custom board with STM32F030 controller on it. In my setup the GPIOs are connected to triac ICs which drive the external load(bulbs). The GPIOs init is as given below:

GPIO_InitTypeDef GPIO_InitStructure;

GPIO_InitStructure.GPIO_Pin = GPIO_Pin_3;

GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;

GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;

GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP ;

GPIO_InitStructure.GPIO_Speed = GPIO_Speed_Level_1;

GPIO_Init(GPIOB, &GPIO_InitStructure);

I am observing an initial spike(on scope) of about 1.5ms on power ON, on the GPIO pin that is connected to one of the triac due to which there is a flicker in the load(bulb). I am not sure what is creating the problem. Any help/suggestions will be very helpful.

Thanks..!!

#stm32-gpio

Danish1 · ‎2015-11-11

Posted on November 11, 2015 at 15:12

10 ms is a ''long time'' for a microcontroller - it is the sort of duration that the microcontroller takes to start executing code from e.g. power-on-reset.

Before the microcontroller has started executing code, the GPIO pin is not driven by the microcontroller so you have to have external components (i.e. an external resistor from the pin to an appropriate voltage level) to keep the pin in a sensible state until your program is running.

Also note that GPIO_Init() sets the pin to be an output - so the microcontroller is driving the pin - but it does NOT specify whether the pin should start out driven HIGH or driven LOW! So if you call GPIO_Init() and then immediately afterwards set the pin to your desired level then it is possible that the pin will momentarily glitch to the wrong state - but I would expect this duration to be much shorter than your observed 10 ms.

Hope this helps,

Danish

yafisdamda · ‎2015-11-11

Posted on November 11, 2015 at 15:33

Thanks for the reply.

It is 1.5 - 2ms. Sorry it was not 10ms. My bad.

So what would be the default state of a pin ?

i am pretty sure the is no resistor connected to the pin.

AvaTar · ‎2015-11-11

Posted on November 11, 2015 at 16:33

>It is 1.5 - 2ms. Sorry it was not 10ms. My bad.

Still quite long. Have you used a scope ?

You can instrument you code with GPIO toggles to correlate it with you code. (Might require patching the startup code to init the GPIOs).

Perhaps you need to do your GPIO initialisation for the Triac-driver also as first thing in the startup code, because system initialisation (clock stabilisation and memory copy/preset) might take too long to be ''invisible''.

>i am pretty sure the is no resistor connected to the pin.

Maybe this is your problem. Try adding a pullup or pulldown resistor, to keep your Triac driver hardware in a defined state during startup.

yafisdamda · ‎2015-11-11

Posted on November 11, 2015 at 19:31

>Still quite long. Have you used a scope ?

Yes i am using a scope.

>Perhaps you need to do your GPIO initialisation for the Triac-driver also as first thing in the startup code

How to i do it? Does it require changes in the startup.s file?

AvaTar · ‎2015-11-11

Posted on November 11, 2015 at 20:09

>How to i do it? Does it require changes in the startup.s file?

Probably.

But I would go for a hardware solution first (pullup or pulldown in the simplest case - ask you hardware designer).

I always disliked the idea of having an inherently unsafe system. Good system design should hold your hardware in a safe state if the MCU is not driving anything - especially if you drive greater power levels.

I've seen boards/chips literally exploding because of those over-reliance on software, just for the extra costs of a fraction of a cent.

yafisdamda · ‎2015-11-11

Posted on November 12, 2015 at 06:17

Thanks for the suggestions.

My hardware engineer just told me there is already a pull-up at the triac side.

Another thing what i observed was the spike was not there all the time. Sometimes there was no/negligible spike. But most of the time there is a spike.

AvaTar · ‎2015-11-11

Posted on November 12, 2015 at 08:57

It is still not clear to me at which time the spike happens. Can you definitely confirm it happens between power-up and GPIO initialisation ?

> Another thing what i observed was the spike was not there all the time. Sometimes there was no/negligible spike. But most of the time there is a spike.

It's IMHO worth understanding why. Perhaps this depends on on-off cycle times, and residual charges in capacitors.In that case, you might try adding a bleeder resistor to this capacitor.

You can try to do the GPIO initialisation of that pin in the startup, as mentioned. Just the call needs to be implemented in assembler, the actual routine could be C code - see the SystemInit() routine for example (I hope you don't use Coocox). But I'm not sure if this really eliminates the problem.

John F. · ‎2015-11-12

Posted on November 12, 2015 at 09:22

Does it help if you write the Output DataRegister with the value you want after enabling the port clock but before GPIO_Init() ?

yafisdamda · ‎2015-11-12

Posted on November 12, 2015 at 11:40

Yes, the spikes appear between power On and GPIO_Init().

I strongly feel that there is some problem at the hardware side, some residual charges at the capacitor like you mentioned. The thing is i want to be sure there is no problem with the software/firmware.

>You can try to do the GPIO initialisation of that pin in the startup, as mentioned.

Can i intitialize GPIOs before enabling the peripheral clocks?