cancel
Showing results for 
Search instead for 
Did you mean: 

PWM on TIM1 CH1 of NUCLEO--F303RE does not start

MCere
Associate

Hello,

I dont't know why in my projetc the PWM daoes not start.

I would generate a PWM with Duty =50% and Period =10msec. I use a NUCLEO--F303RE.

I started with CubeMX to generate the project configuring IO (blinking the green LED) and the PWM on TIM1 CH1 setting the output on PA7.

I see the LED blinking correctly but PWM not working. I see PA7 fixed at 3.3V.

Can you tell me where is my error please? I attach the project Truestudio end CubeMx

Thank you in advance

Marco

5 REPLIES 5

TIM1/TIM8 are Advanced TIM, you must be careful about the larger initialization structures required, and also explicitly enable PWM Outputs . See MOE bit of TIMx_BDTR register. Sorry don't do CubeMX

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

I guess BDTR is to be set in HAL_TIMEx_ConfigBreakDeadTime(); although looking at the attached Cube sources I don't quite understand how

 MODIFY_REG(tmpbdtr, TIM_BDTR_MOE, sBreakDeadTimeConfig->AutomaticOutput);

is supposed to work.

In case it was not obvious, I don't Cube/CubeMX either. Read and check/post the relevant timer registers content. Check by repeated reading of TIMx_CNT register if it is running at all.

JW

Brian D
Associate III

Problem is in the CubeMX TIM1, channel 1 was selected as Output Compare instead of PWM Generation. Go back and select the output mode with PWM Generation CH1.

Brian

> Sorry don't do CubeMX

> In case it was not obvious, I don't Cube/CubeMX either

This question is a STM32CubeMX and HAL question, nothing to do with STM32 MCU, and helpful people like Clive and JW are wasting their time reading it and trying to help even though they "don't do CubeMX", while the mistake (thanks Brian D) was the incorrect usage of a tool, nothing to do with STM32 really.

I think these type of questions should be created/moved to the STM32CubeHAL/LL and/or STM32CubeMX topics. It would be also nice to have separate STM32CubeHAL and STM32CubeLL topics, because I, for example, work with LL but never liked/worked with HAL, so I could go to the LL topic's questions and not waste time with the HAL topic, leaving it to those who know it.

Ideally, the STM32 MCUs section should have separate topics for hardware design, CMSIS level firmware development, STM32CubeMX/HAL, STM32CubeMX/LL, RTOS, and the user should be asked to select one of those topics for his/her question.

Just my Saturday morning coffee-induced thoughts :) sorry for the off-topic.

MCere
Associate

Tank you Brian I Solved it.

Marco​