..

[Jessy J]

..

[Artur IWANICKI]

Posted on June 07, 2018 at 10:44

Hi

houwaydakhemila

‌,

I would suggest you to change Output Compare no output to PWM output as output compare no output will generate only some internal events without any visibility on the pin.

In PWM output configuration timer will take over the control on a given pin (if it is not in use by other peripheral).

What is your target MCU, system clock and desired PWM frequency, please?

Best Regards,

Artur

[Artur IWANICKI]

Posted on June 07, 2018 at 11:42

Hello,

Unfortunately there is no timer available on PG6, PG7, PG10, PG12 where we have LEDs on

#

 

:(

I would propose two options:

- use not used pins (PC6 or/and PC7) to generate PWM signals using assigned timers (we have TIM3_CH2 and TIM8_CH2 connected to PC7 and TIM3_CH1 and TIM8_CH1 connected to PC6) and connect those pins with our LED pins.

- use RAM->GPIO port DMA transfers controlled by any of the timers. This solution has one drawback. If affects minimum 8 lines from PG port and it can be tricky if any other IOs are in output configuration (not alternate function).

Best Regards,

Artur

[Jessy J]

Posted on June 07, 2018 at 11:51

Yes I looked in the schematics and I did not find timer connected to the LEDs

But sorry but i did not understand what you want to say by this 

- use RAM->GPIO port DMA transfers controlled by any of the timers. This solution has one drawback. If affects minimum 8 lines from PG port and it can be tricky if any other IOs are in output configuration (not alternate function).

Thank you for your help

[Artur IWANICKI]

Posted on June 07, 2018 at 12:01

You can transfer data between SRAM located buffer and any register within peripherals area (in particular GPIO->ODR) using any of DMA channels. The best is to select DMA channel which I assigned to any of the timers, so data transfers can be synchronized by timer events.

Best Regards,

Artur

[Artur IWANICKI]

Posted on June 07, 2018 at 12:51

In this case you should use timer's interrupts and toggle pins within proper callbacks. If you are using HAL libraries there would be 2 things to be done: enable interrupts on timer14 and implement your own callback which would toggle the LED, like HAL_TIM_OC_DelayElapsedCallback(). Some example you can find within STM32F4 Cube library in the path: .\STM32Cube_FW_F4_V1.21.0\Projects\STM324x9I_EVAL\Examples\TIM\TIM_OCToggle\

Best Regards,

Artur

[Artur IWANICKI]

Posted on June 07, 2018 at 14:50

LED pins should be configured as Output Push Pull and to change their state you can use one of HAL_GPIO functions, like: HAL_GPIO_TogglePin().

Example you can find within STM32F4 Cube library in the path:

.\STM32Cube_FW_F4_V1.21.0\Projects\STM324x9I_EVAL\Examples\GPIO\GPIO_IOToggle\

Toggling should be done within callback function of TIM14 interrupt.

Best Regards,

Artur

[Jessy J]

Posted on June 08, 2018 at 08:25

I did this but when debug the handler of TIM14 is not working..I checked and I found the systick is enabled . I think that systick is blocking the timer 14 right ?? 

Even though I desactivated the systick from SystemClock Config I did not understand why systick is still enabled

[Artur IWANICKI]

Posted on June 08, 2018 at 10:06

Hello,

If you are using HAL libraries, Systick is used to generate all timings (delays, timeouts) used by functions.

SysTick should not block TIM14. You can compare priorities of both interrupts to check it.

Are you using in your development STM32CubeMX for code generation?

Best Regards,

Artur

[Artur IWANICKI]

Posted on June 08, 2018 at 10:17

Interrupt from TIM14 is not blocked, it is just not enabled. Please come back to STM32CubeMX, Configuration tab, select TIM14 and in its configuration (NVIC Settings) please enable the interrupt which is disabled by default.

It should help.