STM32GO controller PWM Generation issue
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-10-11 4:45 AM
- I'm trying to generate PWM signal using [ TIM3 channel 3] in NUCLEO-G071RB Eval board.
- Time period is 28 microseconds and width are 3 microseconds.
- As you can see in the below [image 1 ]only the first pulse is different or corrupted, which gives 32 microseconds time period and width are 7 microseconds .
- From the second pulse , we are able to get the expected pulse as shown below [image 2] Time period is 28 microseconds and width are 3 microseconds.
- Same behaviour is observed in STM32Cube_FW_G0_V1.6.0 package code, given by STM32 Timer PWM output example code.
Solved! Go to Solution.
- Labels:
-
ST boards
-
ST-Link
-
STM32G0 Series
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-06-06 4:54 AM
Hello @waclawek.jan, @Denial1, @TDK,
This behavior is now noted in Readme files of all HAL TIM examples calling HAL_TIM_PWM_ConfigChannel() with the output channel configured in PWM1 mode:
TIM_6Steps,
TIM_Asymetric,
TIM_CascadeSynchro,
TIM_Combined,
TIM_ComplementarySignals,
TIM_Dithering,
TIM_DMA,
TIM_DMABurst,
TIM_ParallelSynchro,
TIM_PrescalerSelection,
TIM_PWMOutput.
The note is the following:
In this examples, the output channel is configured in PWM1 mode meaning that in up-counting mode, channel 1 is active as long as TIMx_CNT < TIMx_CCR1. As, in the function HAL_TIM_PWM_Start* function, the output channel is enabled prior enabling the timer's counter a timing difference might be observed on the first generated PWM. This difference corresponds to the delay - in term of number of CPU cycles - between the channel enable and the counter enable in the HAL_TIM_PWM_Start* function.
Thank you!
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-10-11 6:43 AM
Hello @Denial1,
Are you overwriting the CCR register directly? Have you seen this behavior after changing the pulse width from 7us to 3us?
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-10-11 6:47 AM
Probably the first pulse starts before the timer is started.
A solution would be to set the CNT of the timer to a value which produces a low state on the pin, rather than a high state. Perhaps set to ARR-1 instead of 0 during initialization. Or otherwise ensure the output state is low during initialization.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-10-13 2:02 AM
Hi @Sarra.S
I'm using HAL library function to start the PWM
HAL_TIM_PWM_Start_IT(&htim3); and
HAL_TIM_PWM_Stop_IT(&htim3) to stop the PWM.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-10-13 2:06 AM
Hi @TDK
I have attached screenshots of STM32cubemx settings. Please look into this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-10-16 2:06 AM
Hello again @Denial1,
I am afraid I couldn't reproduce the issue using the example of the STM32Cube_FW_G0_V1.6.0 package.
So, could you please specify the sequence to reproduce it; have you changed the PSC register value? I am thinking that during the first timer period timer works with another PSC from previous configuration
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-10-18 12:22 AM
Hi @Sarra.S
Thanks for your response!!!!
Path for the example code: -
STM32Cube_FW_G0_V1.6.0\Projects\NUCLEO-G071RB\Examples\TIM\TIM_PWMOutput
I have not changed anything in this example code.
The output can be observed, as shown in the below image 1.
Pin No PA8, PA9, PA10 and PA11 all are having corrupted/ different pulse width of first pulse.
You can easily reproduce this issue, without making any changes to example code.
Looking for your reply!!
Regards,
Denial
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-10-18 2:01 AM
Hello again @Denial1,
Actually, that's exactly what I did, using the same example with the same FW version with NUCLEO-G071RB.
As you can see, there is no first corrupted pulse.
PS: you mentioned "NUCLEO-G071RB Eval board", is that a typo or are you using a custom board?
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-10-18 7:42 AM - edited ‎2023-10-18 7:43 AM
From the waveform capture it's not clear whether the leftmost pulse was the first one after reset (and I am afraid it wasn't).
CubeMX with Cube/HAL provides a quick clicking solution to generate PWM but perhaps does not pay much attention to details like this. If you want anything outside of what the Cube/HAL authors deem usual usage, Cube gets into way more than helps. TDK gave you above the explanation for your problem and also a suggested remedy, just follow his recommendation.
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-10-19 6:00 AM
@Denial1 I apologize for the previous mistake. You're right @waclawek.jan!
I am tracking this issue with an internal ticket (Ticket 164283), I will keep you informed!
Sorry for the inconvenience.
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
