Skip to main content
Smoun.1
Smoun.1
Associate III
September 8, 2020
Question

Nucleo F334R8 - basic example of a Timer TIM2 mystery

  • September 8, 2020
  • 12 replies
  • 2282 views

Hi guys

So I am developing a small PWM generator around the F334R8, it's overall extremely simple. All the work is done with another MCU sending data on SPI.

On the F334R8, an EXT interrupt is called when the CS line is pulled down. From there the F3 listens on its MOSI line, grabs the data, and then outputs the 3 PWM channels on its HRTIM1.

That part is working really well.

I wanted to have a failsafe timeout using TIM2 on a 1second timer.

Basically every 1s a timer interrupt is called, and the program checks for a flag. If the flag is down, then I know that it's been 1s without proper data coming in and that the PWM output should be disabled.

For some reason I can't get that simple TIM2 to work.

So I decided to pull the Nucleo board again and create a super simple project that does nothing but toggle a LED on a 1s TIM2 timer.

  • on the first try I had messed up the RCC because I selected the wrong oscillator. Fixing the oscillator does NOT fix the problem. The LED toggle is still wrong. It toggles at roughly 5Hz, regardless of the TIM2 settings. Changing the period has not impact whatsoever. Still is a slightly different behavior that I am experiencing on the custom board. So, then:
  • I created a new project, same everything, but this time I carefully selected the correct oscillator on the first try, set up TIM2, generated code, compiled. And everything works perfect. 1 s toggles. I can change the period and everything works as expected.

So I am leaving the custom board issue aside for now, and I would really try to find out what's going on.

the 2 projects are identical, and couldn't be more simple. Your typical Timer Interrupt tutorial you find online.

However, one works and one does not. I wonder if CubeIDE somehow generated code when I had the wrong RCC config and fails to update that on subsequent code generations? I really don't know and that's why I'm here.

I uploaded both of these 2 basic projects here: https://gofile.io/d/1LTvVN

test-timer is the one that is blinking at the wrong frequency

test-timer-2 is the working test, which toggles the LED correctly

both of them are very similar. I went as far as reading the main.c line by line and couldn't find anything obvious. I also generated the pdf report but they didn't help.

I would appreciate if anyone could help steer me in the right direction.

thank you

This topic has been closed for replies.

12 replies

TDK
TDK
September 8, 2020

A common issue is that HSE_VALUE is incorrectly defined. Does it match between both projects?

"If you feel a post has answered your question, please click ""Accept as Solution""."
Smoun.1
Smoun.1Author
Associate III
September 8, 2020

Hi, thanks.

I just looked at the ioc file (opened as text file) and for the "bad" project I have:

PF0\ /\ OSC_IN.Mode=HSE-External-Oscillator

PF0\ /\ OSC_IN.Signal=RCC_OSC_IN

PF1\ /\ OSC_OUT.Mode=HSE-External-Oscillator

PF1\ /\ OSC_OUT.Signal=RCC_OSC_OUT

RCC.HSEPLLFreq_Value=8000000

RCC.HSE_VALUE=8000000

RCC.PLLSourceVirtual=RCC_PLLSOURCE_HSE

RCC.RTCHSEDivFreq_Value=250000

and for the good project I have:

PF0\ /\ OSC_IN.Mode=HSE-External-Oscillator

PF0\ /\ OSC_IN.Signal=RCC_OSC_IN

PF1\ /\ OSC_OUT.Mode=HSE-External-Oscillator

PF1\ /\ OSC_OUT.Signal=RCC_OSC_OUT

RCC.HSEPLLFreq_Value=8000000

RCC.HSE_VALUE=8000000

RCC.PLLSourceVirtual=RCC_PLLSOURCE_HSE

RCC.RTCHSEDivFreq_Value=250000

so they're the same, at least in the IOC file.

Or did you mean to look at the generated code in the main.c file?

edit: actually there is no value defined for HSE in the main.c file. Probably in another file, not sure which though

here's what's in the main.c as far as the HSE config:

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
 RCC_OscInitStruct.HSEState = RCC_HSE_ON;
 RCC_OscInitStruct.HSEPredivValue = RCC_HSE_PREDIV_DIV1;
 RCC_OscInitStruct.HSIState = RCC_HSI_ON;
 RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
 RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
 RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL9;

TDK
TDK
September 8, 2020
Well, ultimately, what’s in the code is what actually matters, but it’s probably the same as in the IOC file.
I didn’t trust the download link. If you upload the zip files directly I would take a look.
"If you feel a post has answered your question, please click ""Accept as Solution""."
TDK
TDK
September 8, 2020

Your timer period differs by a factor of 10 between the projects.

0693W000003R6C4QAK.png

"If you feel a post has answered your question, please click ""Accept as Solution""."
Smoun.1
Smoun.1Author
Associate III
September 8, 2020

that's because I saved them at different times. I usually play with various numbers to see if the boards react correctly.

but I can confirm that the 71,999,999 values does give me a 1s toggle on the test-timer-2, changing it to 7,199,999 gives me a 0.1s toggle, as expected.

however, on the test-timer project, changing the value has no impact whatsoever, it always remain the same, roughly 0.2s toggles.

TDK
TDK
September 8, 2020

Okay. You said the projects were identical. They weren't, and the difference would absolutely describe what you're seeing.

It does not make sense that the value in "htim2.Init.Period" has no effect on the program. The only way that could be true is if you're not compiling/running the code that you think you are.

"If you feel a post has answered your question, please click ""Accept as Solution""."
Smoun.1
Smoun.1Author
Associate III
September 8, 2020

I just tried changing the value (Period) in code rather than cubeMX and it went through.

the value you see at 7,199,999 was not getting regenerated when changing the value in CubeMX.

well that fixed it! thank you.

I will now check the custom board to see if a similar problem was happening. - but I doubt it since the interrupt is not firing a regular intervals.

Smoun.1
Smoun.1Author
Associate III
September 8, 2020

sure enough, it's a different issue on the actual project/board.

the 7,199,999 is correct in it.

the symptoms on it (while in debug, with a break point on the gpio toggle), it triggers once immediately, and then nothing, sometimes it will interrupt again a couple minutes later; sometimes not. I've added that project in case you wish to take a look.

Thanks for helping on this on, I never thought of checking the code automatically generated.

TDK
TDK
September 8, 2020

My guess is the system is starved of resources. Disable your other callback and/or put a PWM output on a timer channel if you want to monitor it.

You don't mention how often HAL_GPIO_EXTI_Callback is called. Flip an output pin while it's in that interrupt so you have a sense of how long it spends there.

"If you feel a post has answered your question, please click ""Accept as Solution""."
Smoun.1
Smoun.1Author
Associate III
September 8, 2020

The timer interrupt not firing is actually taking place all the time even when I am not sending data over SPI.

Just as a sanity check, in debug I set a breakpoint in both the timer interrupt callback and the EXT gpio callback.

and as expected without sending data, the EXT GPIO callback is not firing. As soon as I start sending data, the EXT GPIO callback fires. That part is working well.

Only that TIM2 interrupt not firing more than once.

Terms & ConditionsAccessibility statement