Analysis of TIMER3 "interrupt loss" phenomenon

Preface

In a washing machine MC project, the customer chose to use STM32F030 as the main control chip. TIMER3 (CH3) was used to capture the interrupt of the motor's HALL Sensor, and the OC function of TIMER3 (CH2) was used to adjust the speed in the OC match interrupt. During debugging, the customer found that when the capture interrupt and the OC interrupt "occurred at the same time (aligned)", the capture interrupt would be lost.

problem analysis

The customer initially discovered that when using this configuration to control the motor, the motor speed would be abnormal at a certain moment. After capturing the waveform, it was found that the HALL Sensor and the capture output waveform (flipping IO in the interrupt ) did not match. At a certain moment, the " interrupt loss " phenomenon would occur, which was manifested as the capture output high or low level cycle being lengthened, as shown in Figure 1. Yellow is the HALL signal, green is the capture interrupt output, and purple is the OC interrupt output. It can be clearly seen that after the fourth rising edge, the high level length is lengthened by half a cycle. The customer suspected that the hardware bug caused the capture " interrupt loss " when the interrupt " occurred simultaneously " , thus causing this problem.

Figure 1

Check Erratasheet , there is no relevant description. In addition, the possibility of interrupt loss caused by hardware bug is small, because the probability of interrupts occurring at the same time is very low and the phenomenon is easy to reproduce.

Build a test environment

The corresponding test project is built through CubeMx , and the IO is flipped in the capture and OC interrupt to detect the interrupt status. In addition, the corresponding PWM is generated through other development boards to simulate the HALL signal. After testing, it is found that the code generated by the Cube library does not have the phenomenon of " lost interrupt " , and the waveform is shown in the figure below .

Code Analysis

The customer's code, including the interrupt service function, is written by directly operating the register. After analyzing the customer's code, it is found that when the customer clears the relevant interrupt flag in the interrupt service function, it is completed through the commonly used register operation method " read - modify - write " , as follows:

TIM3->SR&= ~TIM_SR_CC3IF; /* Clear the flags */

In the HAL Driver , it is cleared by directly assigning values ​​to the corresponding bits, as follows:

#define__HAL_TIM_CLEAR_IT(__HANDLE__, __INTERRUPT__) ((__HANDLE__)->Instance->SR= ~(__INTERRUPT__))

Combined with the phenomenon observed by the customer, it is suspected that the possible reason is that the capture interrupt flag is set between reading the status register and writing the register . In this case, the flag may be cleared without being detected and processed, resulting in an exception.

The problem was reproduced by modifying the interrupt service function in the HAL Driver function to the same " read - modify - write " method as the customer to clear the corresponding flag bit.

summary

If you integrate the underlying driver by directly manipulating registers, you must be extra careful when manipulating such registers that are modified by hardware through the " read - modify - write " method. Depending on the specific description of the register, you can modify it by direct writing or by union (bit-by-bit modification).

===============================

Links to previous topics:

1. ST's new all-in-one programming software STM32CubeProgrammer

2. Case sharing of abnormalities when the clock is adjusted up

3. Code performance comparison based on different STM32 library functions

4. Case studies on power supply in STM32 application

5. Ways and means to obtain ST MCU technical information and related support