In my nucleo L432KC, I have set Timer 1 for PWM generation, Timer 15 as a timer based interrupt and Timer 2 as PWM input mode. Timer 1 and Timer 15 works well until a point. My clock frequency is 2MHz. For example, I wanted a 50 kHz update event, so I set Timer 15 Precaler 0 and period 39. In that case, While(1) loop never executes, i.e, the program hangs.

When I start timer 2 as:

HAL_TIM_IC_Start_IT(&htim2, TIM_CHANNEL_3);

HAL_TIM_IC_Start_IT(&htim2, TIM_CHANNEL_4);

My timer 1 misbehaves. The program in general misbehaves. What could be happening here? It's like Timer 15 interrupt is taking all the control? Is something related with interrupts priorities? The purpose of Timer 15 is to fire an interrupt at 50 kHz. During this interrupt, I'm reading SPI data.

Pseudocode of interrupt routine:

Pull chip select down

Read SPI with HAL_SPI_Receive

Pull chip select up


If you have an interrupt firing at a frequency of 50 kHz with a 2 MHz clock for your core, that leaves 40 clock cycles to do work between two interrupts.

That is quite few, it already takes some cycles to enter and leave the interrupt, so you get even less for actual work.

In the comment you stated that you are "simply" reading some SPI data. If it would be just transferring data out of the SPI data register, that might be fine - but then you would do that in an SPI interrupt. So I guess this reading involves more than that.

And with that I am pretty sure that you need more cycles in the interrupt routine than available. Which results in the next timer interrupt being queued up while still handling the old one.

In that case you are never going to leave the interrupt and the rest of the program will never get the chance to execute. Interrupt priorities might change this a bit (other interrupts will be handled) but you will not get to your main code.

To change this you either reduce the frequency of the interrupt or increase the clock frequency of the core.

  • \$\begingroup\$ Thank you. I will increase clock frequency of the core. \$\endgroup\$ – Blue_Electronx Oct 17 '18 at 14:36

Reading the SPI in the timer interrupt is just wrong and your application requires reconsideration. You have SPI interrupts to do so or if the speed is higher you need to use DMA for the communication.

So changing the frequency will not make your code correct. Only the correct usage of peripherals will.

  • \$\begingroup\$ I reconsidered the idea. I decided to read the SPI in the main loop. \$\endgroup\$ – Blue_Electronx Oct 18 '18 at 12:19
  • \$\begingroup\$ It is another option as well \$\endgroup\$ – P__J__ Oct 18 '18 at 12:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.