Possible silicon race condition on STM32F4

marbel · ‎2012-10-07

Posted on October 07, 2012 at 18:29

The original post was too long to process during our migration. Please click on the attachment to read the original post.

waclawek.jan · ‎2012-10-08

Posted on October 08, 2012 at 17:27

TIM_OC2PreloadConfig(STABLE_TIMER, TIM_OCPreload_Disable);
 Why?
 JW

marbel · ‎2012-10-08

Posted on October 08, 2012 at 22:53

Later on in the application code, i needed to change the location of the CC2 pulse and that the new value would be taken into account directly and not at the next update event.

Anyway. Changing it will still trigger the problematic edge.

// Martin

waclawek.jan · ‎2012-10-09

Posted on October 09, 2012 at 10:00

Okay, but a couple of lines above that you enable it. In the lines meantime you don't force an update event nor can I see why an implicit update event would happen. I may be wrong of course.
 Look I don't pretend I understand what is causing your problem. The timers in STM32 are an incredibly complex stuff, but I am afraid you make it worse by your approach.
 You might want to reduce further your example by using explicit values instead of layers of macros, and by describing in detail what exactly do you want to achieve. There might be alternative ways how to achieve that.
 JW

waclawek.jan · ‎2012-10-09

Posted on October 09, 2012 at 10:08

One more thing:

> If I use the reset button to trigger the boot of the system I never get the small pulse on the purple channel.

If you use the debugging facilities, they do/may influence the way how the timers behave. Look at chapter 32.16.2. There may be undocumented subtleties involved, and what I said above about the incredible complexity of the timer, applies here too.

JW

waclawek.jan · ‎2012-10-10

Posted on October 10, 2012 at 13:16

One more thing:

// TIM_ITConfig(STABLE_TIMER, TIM_IT_CC1 | TIM_IT_CC2 | TIM_IT_Update, ENABLE);
TIM_ITConfig(STABLE_TIMER, TIM_IT_Update, ENABLE);

which means, in the code you posted, the CC interrupts are not enabled. How comes then, that on the traces we see ''blue'' pulses? It is important that you post findings consistent with the posted code, otherwise you waste time of those who try to reproduce/understand/explain your problem. JW

marbel · ‎2012-10-15

Posted on October 15, 2012 at 13:00

JW,

Thanks for your time on this. In the end, I found out that the only way to get a consistent result was to add a:

TIM_DeInit(STABLE_TIMER);

Just after the RCC inits in the beginning of the main code. And you are right. I should have cleaned up my example code more. But nevertheless, the chip did behave inconsistent. In the future, I will always call DeInit before initializing my timers. Best regards Martin

waclawek.jan · ‎2012-10-15

Posted on October 15, 2012 at 13:48

Thanks for coming back with the solution which worked for you.

I guess this boils down to incomplete reset when relying on the reset facilities of the debugger. I'd guess, if you'd read out the timer's registers just before the ''deinit'' function call, they wouldn't be in their reset state.

JW