cancel
Showing results for 
Search instead for 
Did you mean: 

Time base interrupt STM32G4 HAL overflowing?

CMart.8
Associate

Hello everyone,

this is my first post here, please my apologies if I mistake some terms since we jumped into the ST controller world in the company around 6 months ago and I am still learning about the technologies.

I have been working so far on a project on STM32G474 Nucleo board with IAR, basically a control system giving out PWM outputs for a valve on a 50kHz control loop running on an interrupt, with FreeRTOS on top to look after non-RT tasks like CAN communication, EEPROM handling over SPI, and some big computations that cannot be done in real-time.

I started running into random problems that manifest as CAN communication not working, irregularities in the PWM and parameters not being written / read from EEPROM correctly. The conditions for coming into this errors are difficult to pinpoint, I add some function call somewhere and the whole application starts showing problems.

Today I started investigating the interrupts in the system, from which I use:

  • TIM7: HAL time base
  • TIM1: application
  • DMA1...5: ADC conversions

Below is a capture of the interrupt log of the system running for some microseconds. The "overflow" means that IAR could not get some of the interrupts.

I have several questions:

(1) Does it really make sense that the void TIM7_DAC_IRQHandler(void) function needs 268 cycles to run, if it is called with 1MHz in a system running with 170MHz? 268 cycles need 1.57us, which is more than the interval between interrupts.

(2) Apart from that, I see that probably the interrupts are stacking (Status column is moving to the right), but maybe it is related to the problem with IAR losing information?).

(3) TIM1_UP_TIM16 (my application interrupt) should be called with 10kHz (I reduced it for debugging), but here I see two "Enter" at cycles 715644 followed by 715936, that is with 292 cycles difference. In theory the calls should be spaced 17000 cycles (100us). Any idea what could be the reason for this? And it is leaving the interrupt after 0 cycles, so IAR.

Thanks in advance for any hint!

0693W00000Bb7UVQAZ.jpg

2 REPLIES 2

I don't know how much from this are IAR artefacts, but it's unreasonable to run a 1MHz interrupt.

Also, if you want faster running interrupts, enable compiler optimization and ditch Cube.

JW

CMart.8
Associate

I think it might be a problem with the IAR development environment and the ST-Link v3. Even if I lower the CPU clock from 170MHz to 40MHz I still get overflows in the interrupt log in the SWO traces. Thanks for the link!