1
votes

I've built a project based on the example code found in STM32Cube_FW_L4_V1.15.0\Projects\NUCLEO-L432KC\Examples\TIM\TIM_PWMInput. The Nucleo board I'm using is the NUCLEO-L432KC and I'm programming it with STM32CubeIDE 1.3.0.

As the project grew larger, I tried to organize the code better in a new project with header and source files because almost everything was in main.c except for the normal files found in an STM HAL project. I eventually got the code running with the new and reorganized project created as an STM32 Project in STMCubeIDE. However, it runs super slow compared to the project with most of the code in main.c, which is weird since it is mostly defines, inits and such. In main.c I have the infinite loop and HAL_TIM_IC_CaptureCallback(). The loop looks like this:

  while (1)
  {
      if (TIM15_DutyCycle > 50 && TIM2_DutyCycle < 50)
      {
          BSP_LED_Off(LED3);
          DWT_Delay_us(200);
      }else
      {
          BSP_LED_On(LED3);
          DWT_Delay_us(200);
      }
  }
}

It generates a signal which I read the frequency of with another Timer. Now the problem is that this code works from the example project but not the new project. With an oscilloscope, I see that the signal is still generated so the code is running, but the timing is completely off and really slow. I guess my question is what could cause this? Could organizing the code in several files cause too much context switching and slower execution? Or could it be some project setting in STM32CubeIDE that causes this? I haven't found any difference yet. Clock settings etc should all be the same but I could have missed something even though it is mostly copy-paste from the other project, only reorganized. No compiler errors or warnings are given from any of the projects.

I realize these are quite general questions but since my code has the expected behavior in the original project I thought showing all of the code might not be necessary. Maybe someone has experienced something similar before?

1
Arranging of code in different files is for user readability/understanding. Impact of re-arranging code into files should be zero on performance. - Babajan
Did you try to measure execution times of some functions? If you have at least one pin free, you can use that with different pulses and use an oscilloscope or a logic analyzer to look where the time is lost. This additional stuff takes some time, though. - the busybee
Measuring the performance of the code with delays does not make any sense - 0___________

1 Answers

0
votes

Could organizing the code in several files cause too much context switching and slower execution?

No.

My first guess is that you inadvertently changed a clock setting. Did you change the SystemClock_Config()?

Enable the Master Clock Output (MCO) pin and then use your oscilloscope to check that the clock is running at the expected frequency (80 MHz?). Add this line after the call to SystemClock_Config() to enable the MCO. This assumes that you are using the PLL like the example.

SystemClock_Config();
HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_PLLCLK, RCC_MCODIV_1);

My second guess is that you have a bug in your code and it does not behave like you're expecting. You'll need to show more of your code to get help with that. For example, show the timer configurations and show DWT_Delay_us().