RTC second counting uneven problem

Problem Description:

This problem was raised by a customer and occurred on the STM32F103RBT6 device. According to the engineer, the product is a vehicle-mounted GPS navigation monitoring device, which uses STM32 as the main control device to manage the entire device. In the design of this product, the STM32 RTC is used, and its timing is displayed on the screen of the product. The update of the timing display is completed by the second interrupt of the RTC, that is, the second interrupt service program of the RTC reads the new time from the RTC and updates it to the relevant variables, and then triggers the screen refresh program to update the display on the screen.

During the test, it was found that the seconds part of the time displayed on the screen was not running evenly, sometimes fast and sometimes slow, and even lost a certain intermediate value and jumped. The long-term timing of the displayed time was measured and found that the long-term timing was accurate, that is, the average value of the second length was accurate. Turn off other interrupts in the program and only keep the RTC second interrupt, and the problem still exists. By adding the code for GPIO flipping in the RTC second interrupt service program to measure the time interval of the RTC second interrupt response, it was found that it was uniform , as shown in Figure (I), indicating that the fluctuation of the displayed time is not caused by the untimely response of the RTC second interrupt.

The same method is used to measure the time consumed from the response of the RTC second interrupt to the completion of the update of the screen display time. The result is 1.56mS, as shown in Figure (2). This delay is not enough to cause a noticeable fluctuation in the screen display time. At this point, I don't know how to locate the cause of the problem next.

Research:

Repeat the observation as described. To facilitate observation, modify the code so that after each new time is read from the RTC, the variable storing the time is printed to the terminal software via UART. The result is shown in Figure (III), which is consistent with the time displayed on the device screen:

The code is further modified to add a 1mS wait before each time reading time data from the RTC, as shown in Table (I), where the variable TimeDisplay is set to "1" by the RTC second interrupt service routine, triggering the task to update the screen display time.

Void Tim_Show(void)

{ /* infinite loop */

While(1)

{/* if 1 second has passed */

If (TimeDisplay==1)

{/*display current time */

Delay(1) // Delay 1s before reading time from RTC

Time_Display(RTC_GetCounter());

TimeDisplay = 0;

GPIO_WriteBit(GPIO_LED,GPIO_Pin_6,Bit_RESET);

}

}

}

After compiling and retesting, the results show that the phenomenon described above no longer occurs.

Conclusion and treatment:

The reading of RTC time by the user program and the updating of time data by the RTC itself compete with each other in terms of timing, so the operation order of the two is uncertain. As a result, the read time data is sometimes new data and sometimes old data, which causes the value of the read back time data to jump or remain unchanged instead of steadily increasing.

By adding a certain delay before reading the RTC time data, a fixed time sequence is maintained between it and the RTC internal data update, so that the data read back are all updated data.

In-depth analysis:

In STM32, the RTC part and the CPU belong to different clock domains, and the working clock frequencies of the two are quite different. The former works at a frequency of 32.768KHz, while the latter usually works at a frequency of more than 36MHz. This difference leads to a significant difference in the speed at which the two respond to the same event, with the CPU responding faster and the RTC responding slower. From the RTC system architecture shown in the figure below, it can be seen that the second pulse signal generated by the pre-divider is sent to the RTC counter and is also sent to the CPU's NVIC unit through the RTC interrupt request control unit.

Such a signal transmission relationship determines that the RTC second interrupt request signal is sent to the CPU at the same time when the RTC counter receives the update count signal, rather than after the RTC counter completes the update count. In this way, since the RTC response time to this event is one clock cycle of the RTC clock domain, that is, 30.5us, and the CPU response time to this event is only a few to dozens of clock cycles of the CPU clock domain. If the CPU works at a frequency of 36MHz, generally this time is about 330ns, so the CPU must respond to this event before the RTC counter. However, in general, the software interrupt service program does not read the RTC time data at the beginning, but must first do some preliminary judgment and preparation work, and even wait until the interrupt service program ends before the ordinary task reads this data. As a result, a delay will also be triggered, usually the delay duration is between 10uS and 50uS. Therefore, the event of reading the RTC time data and the event of updating the count value of the RTC counter occur at very close time points, and there is no fixed order. To sum up, the temporal relationship of several events is shown in the figure below:

In order to eliminate the time competition between the RTC counter updating time data and the software reading the RTC time data, the latter event can be delayed for a period of time to ensure that the two events have a fixed order.

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

Links to previous topics:

1. Flash erase and write operations cause USART data loss

2. Cases where the serial port sometimes receives abnormal data when working in DMA mode

3. Two topics about USB DFU IAP routine porting

4. Analysis of the problem of USART interrupt receiving no response

5. Topics on transmission anomalies related to DMA FIFO applications