cancel
Showing results for 
Search instead for 
Did you mean: 

Unexplainable Glitching on STM2F4 (or maybe not)

Rogers.Gary
Senior II
Posted on February 19, 2015 at 18:10

The original post was too long to process during our migration. Please click on the attachment to read the original post.
3 REPLIES 3
Rogers.Gary
Senior II
Posted on February 20, 2015 at 05:00

Bump.

I really need some help on this. Can anyone take a look at this code and help me out?

Danish1
Lead II
Posted on February 20, 2015 at 11:10

The first thing I will say is that 100 ms is a ''long time'' in microcontroller terms.

So we might ask what might your stm32 be doing that takes 100 ms?

Looking closely, I see that your green trace seems to have a small sine wave during the 100 ms that your yellow trace is high. A credible explanation is that both pins are floating, and that your external hardware happens to pull the yellow trace high and the green trace low during this 100 ms.

So my next thing question is when might you assign both pins to be floating inputs?

My answer:

At power-up/reset, I expect all pins to be floating inputs except where specified by the data sheet (e.g. those which can be used by JTAG have specific pull-up/down to comply with JTAG specs without the need for external resistors).

And I would also expect GPIO_Deinit to put the pins back into this state.

So what is taking 100 ms?

That might be the time from your debug system resetting your processor to it coming out of reset and calling GPIO_Configuration();

Hope this helps,

Danish

Rogers.Gary
Senior II
Posted on February 20, 2015 at 21:49

hi danish,

thanks for the help. After a bit of investigation I realized that the pin in question was mapped to the Discovery's accelerometer (SPI_CLK) and it was objecting to being remapped. (wonder why)  ;--)

After sending to an AF and a different channel (OC2) it's now working correctly.