Setting up timers and toggling pins using CubeMx

[Amir1]

Dear All

I am trying to use one of the timers on F303RE to toggle a pin at every count-up overflow event (let us say I need a jitter-free pulse). From CubeMx I get the impression that a GPIO pin can be associated with a timer and toggled by the event directly, that is without an interrupt. However, CubeMx does not seem to be generating the code that would be needed for setting the GPIO pins that have been associated with the selected timers. I have tried both Tim3 (associated with PA6) and Tim15 (associated with PB14), but no pulse appears at the pins. Again, I am not surprised because no code gets generated by CubeMx for setting the mentioned GPIO pins or for calling any TogglePin function. By contrast, I am seeing the code for setting GPIOA and GPIOC (for the LED and the blue button, respectively) as well as a HAL_GPIO_WritePin function for the LED), but nothing similar appears in the code for PA6 or PB14! I am not sure why this is the case.

Any insight will be greatly appreciated.

Amir

[S.Ma]

Have you defined the timer GPIO pins on CubeMX?

It's fine to overrides post MX init code with whatever is needed to make it work and get the timer channel out. You can even in debug mode, stop the program and manually edit GPIO and Timer registers to see your toggle output on a oscilloscope if needed. MX is yet to support applicative level needs such as drag and drop part numbers, setting bus based on bandwidth speed, setting waveforms in Hz and steps, etc...

[Amir1]

In CubeMx, GPIO pins PA6 and PB14 appear under the timers' GPIO settings for TIM3 and TIM15 as well as under Tim3 and TIM15 in the GPIO settings. The also appear on the Pinout view. Beyond that, I am not sure what is left to be defined. As you said, I can try to modify the code to get the output out but I wondered why the code is not generated automatically (unlike those for PA5 and PC13 do). I will inspect the registers in the debug mode to see what happens and whether or not the scheme works internally at least.

[S.Ma]

There is option to generate separate C file for each peripheral type. Do so and run debugger.

There is nothing better than inspect HW registers after a breakpoint. Get an oscilloscope (the embedded world) instead of a logic analyser (the linux embedded world) ;)

[Amir1]

Thanks. Generating separate C and h files was a good idea; it helped me find the hidden code that turned out to be under tim.c file (defining PB14 as an alternate function, not not appearing under regular GPIO). The issue of maloperation was that it had not ocurred to me that I had to start the timer using HAL_TIM_OC_Start(&htim15, TIM_CHANNEL_1). I called the start function in the main section and before the while(1) loop, and all is working now as expected.

However, the waveform is noticeably jittery at about 140-250kHz. I switched the clock off from the PLL and put it onto the RC oscillator. Then the stability got a bit better, but it is still not very impressive. I expected a much cleaner waveform given this is a hardware timer.

[S.Ma]

Hmm, jitter means what exactly? Value? If you have an oscilloscope, monitor the PWM output, what is the trigger source? What is SYSCLK core frequency? 48+ MHz? Then the timer should run at 24 MHz giving you a period of 250*24 steps.

[Amir1]

It is not PWM as such. It is bit toggle at every overflow event. I have used internal clock. Oscilloscope shows that the edges of the waveform move back and forth by as much as 80ns. The time clock was originally 72MHz, coming from the PLL. I later changed it to HSI, which brings the clock down to 8MHz. Once I know the clock freq., I set the preload value accordingly to get the output frequency I want (0XF for 250KHz on an 8-MHz clock, for example). The issue is present regardless of the clock source, and I bet that the issue is also present at any frequency, but it becomes more visible at high frequencies since the edge movements constitute a larger percent of the overall period and thus fill a larger portion of the oscilloscope time access.

[S.Ma]

Can you turn on the MCO clock output GPIO and prescale it to check if it has jitter?

MCU has basic prescaler and very few registers to tune.

[Amir1]

I do not see MCO in the clock configuration tree. From what I see, all timers can be configured to be clocked by PLLCLK, PCLK1, or PCLK2. These in turn are derivatives of either HSE or HSI, which I have tried with the same result. Even SysTick timer seems to be fed from the same sources.

[Amir1]

Further, I also configured TIM2 for a PWM generation on PA0; the same jitter issue here too. The clock source is PCLK1 and 72MHz. These must be coming from the clock sources. The while(1) loop is empty. So this must all be hardware related. I ran a quick search. Looks like a known issue.