AnsweredAssumed Answered

STM32F4xx HAL_TIM_IRQHandler misses interrupts on nearly overlapping TIM interrupts

Question asked by Dan K. on May 29, 2014
Latest reply on Jun 20, 2014 by Clive One
I have ported the STM324x9I_EVAL TIM_OCToggle project to the NUCLEO-F401RE from the following project:
 STM32Cube_FW_F4_V1.1.0\Projects\STM324x9I_EVAL\Examples\TIM\TIM_OCToggle

The TIM3 prescaler was set to generate a CK-CNT clock of 21 Mhz and a BSP_LED_Toggle(LED2) was added to the HAL_TIM_OC_DelayElapsedCallback( ) HAL_TIM_IRQHandler ISR callback function to be able to monitor the interrupts that occur.

Using a logic analyzer to monitor the TIM3 channel 1, 2, 3, and 4 outputs (as well as the LED2 LED), I noticed that there were periodically large gaps in the output pulses on the various Output Compare channels. This appeared to be occurring when multiple TIM3 interrupts occurred nearly simultaneously. It appears that TIM3 Output Compare event interrupts are being lost!

I changed the uhCCRx_Val values to the following: (see lines 54 to 57 in the original main.c)
  __IO uint32_t uhCCR1_Val = 1000;
  __IO uint32_t uhCCR2_Val = 1001;
  __IO uint32_t uhCCR3_Val = 1002;
  __IO uint32_t uhCCR4_Val = 1003;

and the problem is much more pronounced with all channels operating at nearly the same CCRx period of about 10.6Khz. (If all channels have exactly the same period, the problem does not seem to occur - even though all four TIM3 Output Compare event interrupts occur simultaneously.)

I have checked the STM32F401RE Version 2.0 Errata Sheet and there is no mention of any interrupt issues.

In the attached .zip file is the hex file of the test application code I'm using on the NUCLEO-F401RE.  The TIM3 channels 1 to 4 Output Compare outputs can be observed on PC6, PC7, PC8 and PC9 (NUCLEO Morpho connector CN10-4, CN10-19, CN10-2, CN10-1) and LED2 can be observed on PA5 (NUCLEO Morpho connector CN10-11).

Also in the attached .zip file are two screenshots (MissingInts1.PNG and MissingInts2.PNG) of the logic analyzer output of the monitored signals. In the first image file is approximately the first 50mS output after the board reset. As can be seen in the gaps in the output data, all four channels have corrupted output in their waveforms. In the second image file is a zoomed in view of the first image file of about 500uS of data starting about 165uS after board reset in which the TIM3 outputs start showing problems. The LED trace toggles each time the HAL_TIM_OC_DelayElapsedCallback( ) function is called from the HAL_TIM_IRQHandler( ) ISR. The following items in this image are of interest:
       
  1. starting at the 1st rising edge of CH1-CH4, the LED2 trace shows only 3 of the 4 signals were processed, resulting in CH4 not timing out in its expected period (note that in actuality, CH1 occurred 1st, followed ~200nS later by CH2, followed ~200nS later by CH3, and then ~200nS later by CH4)
  2.    
  3. starting at the 2nd rising edge of CH1-CH3, the LED2 trace shows only 2 of the 3 signals were processed, resulting in CH3 not timing out in its expected period (note that in actuality, CH1 occurred 1st, followed ~300nS later by CH2, and then ~250nS later by CH3)
  4.    
  5. starting at the 5th falling edge of CH1-CH2, the LED2 trace shows only 1 of the 2 signals were processed, resulting in CH2 not timing out in its expected period (note that in actuality, CH1 occurred 1st, followed ~500nS later by CH2)
The following are the MCU information reported by the STM32F401RE on my NUCLEO-F401RE:

NUCLEO-F401RE
STM32F401RE
CPU ID: 0x410fc241
        Implementer : 0x4
        Variant     : 0x0
        Constant    : 0xf
        PartNo      : 0xc24
        Revision    : 0x1
MCU ID: 0x10006433
        Revision : 0x1000
        Device   : 0x433
HAL Version: 0x01000000
CMSIS Version: 0x02000000

Attachments

Outcomes