You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by di...@gmail.com on 2021/04/04 08:13:07 UTC
TIMER thougt-problem COUNT and TIME BASED together STM32F4xxx
I Tried to show the difference (debug) in one image....
https://imgshare.io/image/image.p307iH
I tried to state the differences... according the reference sheets and application notes from the STM32F4xx family this should work "together".... where you use say TIM1 (or TIM8) [ADVANCED TIMERS] with "COUNTS" and where you say use TIM9 (or any other [GENERIC TIMER] in say "time bases" mode.
What am I doing wrong? And how could I tackle this to get it working?
Is seems (according tot he debug output) that its a "driver" implementation and that the CONFIG_PWM_PULSECOUNT KConfig is causing this behaviour??
Thanks you for thinking with me...
Ben
Re: TIMER thougt-problem COUNT and TIME BASED together STM32F4xxx
Posted by raiden00pl <ra...@gmail.com>.
If PULSECOUNT is enabled, current logic in stm32_pwm.c assumes that all PWM
instances support PULSECOUNT which is not true. Timers without RCR register
shouldn't use pwm_pulsecount_* functions. Probably that is the problem.
I guess you can do something like this:
https://github.com/raiden00pl/incubator-nuttx/commit/dc30c50d161cc7d4cbea849f8d46dc35924e51fe
I haven't tested it, haven't even compiled it, but I guess that's the way
to fix the problem.
niedz., 4 kwi 2021 o 10:13 <di...@gmail.com> napisał(a):
> I Tried to show the difference (debug) in one image....
>
> https://imgshare.io/image/image.p307iH
>
> I tried to state the differences... according the reference sheets and
> application notes from the STM32F4xx family this should work "together"....
> where you use say TIM1 (or TIM8) [ADVANCED TIMERS] with "COUNTS" and where
> you say use TIM9 (or any other [GENERIC TIMER] in say "time bases" mode.
>
> What am I doing wrong? And how could I tackle this to get it working?
> Is seems (according tot he debug output) that its a "driver"
> implementation and that the CONFIG_PWM_PULSECOUNT KConfig is causing this
> behaviour??
>
> Thanks you for thinking with me...
> Ben
>
>