0
votes

I've got a strange issue I can't seem to get my head around. I'm using a STM32F411 board and ST32CubeIDE (eclipse based). I want to use PWM so I've used cubeMX to configure TIM4 in PWM output mode, with a prescaler and load value that is appropriate for the PWM frequency/pulse widths I want. I've also enabled global interrupt for TIM4 as I want to use the HAL_TIM_PWM_PulseFinishedCallback function later on.

Before the main loop, I initialise TIM4 and all 4 channels as so:

HAL_TIM_PWM_Start_IT(&htim4, TIM_CHANNEL_1); //Start up PWM
HAL_TIM_PWM_Start_IT(&htim4, TIM_CHANNEL_2); //Start up PWM     
HAL_TIM_PWM_Start_IT(&htim4, TIM_CHANNEL_3); //Start up PWM     
HAL_TIM_PWM_Start_IT(&htim4, TIM_CHANNEL_4); //Start up PWM

Then after I just set the PWM pulse widths manually:

htim4.Instance->CCR1 = 100;
htim4.Instance->CCR2 = 100; 
htim4.Instance->CCR3 = 100;
htim4.Instance->CCR4 = 100;

For some reason however, when I turn compiler optimisation on 'Optimise for speed -Ofast'* the program seems to get stuck after the final line, whilst debugging, where CCR4 gets set, and can't progress.

This only happens when compiler optimisation for speed is enabled. By default it was set to optimise for debug and it was fine that way.

1
It'd be helpful to show the code that you actually can't debug. BTW, what compiler/debugger is this? - followed Monica to Codidact
Please don't use quote formatting for pieces of code. - Tarick Welling
Apologies - fixed, it's STM32Cube IDE which is STM's own IDE that is essentially eclipse based. There isn't much code before that, apart from the cubeMX's autogenerated code. It's these specific lines that are where the program get's stuck. - Nick Savva

1 Answers

1
votes

Optimizing for anything but debug can confuse the debugger.

Things that you can try: (You didn't specify your toolchain, I'm assuming it's something eclipse/gcc based.)

  • Enable instruction stepping to step through the assembly instructions one at a time. It should work even when debugging by source lines doesn't.
  • Set a breakpoint two or three lines further down in the code, and let the debugger run through the critical part.
  • Hit the pause button just to see where it got stuck. It might not be available if you don't have an active breakpoint somewhere in the code.