Time Drift Between 2 Identical Black Pill boards

[TTT]

STM32F401 (Blackpill) – 2.4s Drift in 30 Minutes Between Two Identical Boards Using TIM2 (HSI Clock)

I am working on time synchronization between two identical Blackpill STM32F401CCU6 boards.

Both boards:

• Use internal HSI oscillator

• Same firmware

• Same clock configuration

• TIM2 configured as 1 MHz free-running counter (1 µs resolution)

• 32-bit counter (auto-reload = 0xFFFFFFFF)

Clock configuration:

• HSI ON

• PLL enabled (HSI → PLL → SYSCLK)

• SYSCLK = 32 MHz

• TIM2 prescaler = 31 → 1 MHz timer tick

Initialization

• Both boards started in STANDALONE mode
• Both boards waited for button interrupt
• The board which gets interrupt became MASTER

Synchronization Method

• One board acts as MASTER

• Other board acts as SLAVE

• Communication via UART (115200 baud)

• Master sends a 5-byte sync packet:

  • 0xAA + 4-byte counter value

• Slave receives and sets:

  htim2.Instance->CNT = received_counter; 

• UART disabled and connection removed

Initial sync works correctly.

Problem

After synchronization:

• Drift increases over time

• After 30 minutes → ~2400 ms difference

• After 50 minutes → ~3200 ms difference

This corresponds to approximately:

~1300 ppm difference between the two boards.

Both boards are identical and running the same firmware.

Questions

1. Is this drift expected when using HSI?

2. What is the typical HSI accuracy (ppm) for STM32F401?

3. Would switching to:

   • External crystal (HSE)

   • LSE
     significantly reduce drift?

4. Is there a recommended method for long-term time synchronization between two STM32s without external clock sharing?

Additional Notes

• No hardware clock sharing between boards

• No external crystal currently used

• Only UART connection between boards, and removed after sync

I would appreciate any guidance on improving long-term timing stability.

Thank you.

 

[mfgkw]

Hi,

 

I would not expect more precision.

BTW if I calculate correctly it's not 1300ppm but 1070ppm or around 0.1%. That is ok for an oscillator, and some more deviation would be ok as well.

If you need more accuracy then a crystal would be better (both LSE or HSE are possible). But even then you can not expect 100% accuracy over a long time.

[mƎALLEm]

Hello @TTT and welcome to the ST community,

Did you refer to the datasheet?:

This is is for an ST genuine chip (genuine STM32). I'm not sure what you have on that Black Pill board.

Meanwhile, if you are measuring the time in one second precision HSI is not the right clock source. You need to use a crystal and use it with RTC and LSE.

[TTT]

Thank you for your interest,

I refer for RM0368 Reference manual STM32F401xB/C and STM32F401xD/E advanced Arm®-based 32-bit MCUs, I can not find your table. I am not sure about the chip is genuine, and here the page of the board:
https://stm32-base.org/boards/STM32F401CCU6-WeAct-Black-Pill-V1.2.html

[mƎALLEm]

There are two main documents for a product:

The user manual: mainly for the peripheral and register description. In your case RM0368

The datasheet: manly for the electrical characteristics. In your case DS9716  /Table 39. HSI oscillator characteristics 

The errata sheet can also be considered a recommended document to refer to. It provides the limitations in the product as well as some workarounds of these limitations. In your case: ES0222

 

---

@TTT wrote:

I am not sure about the chip is genuine, and here the page of the board:
https://stm32-base.org/boards/STM32F401CCU6-WeAct-Black-Pill-V1.2.html

---

I cannot confirm if it's genuine or not but what we now is that these "Coloreful" (Blue/Black) Pill boards may contain a counterfeit chips.

[unsigned_char_array]

What's the goal?

You can use a more precise clock source, trim the internal clock, or compensate for error in software.

You can check out application note: AN5067

[TTT]

Here is the goal,

I am dealing with video streaming in some projects, and I need some solution about measuring latency between camera and display. I designed a solution with a single board and works fine but actuator and sensor were wired to it thus I can not done measurements in long distances.

As solution, I thought about 2 identical boards and time sync between somepoint. Then, I will seperated and position them in front of camera and display that are actually far apart from each other. 

I am aware that the oscillators may affect from environmental changes such as temperature, humidity, vibration etc., and physical impossibility about manufacturing identical boards, components ...

I am ok with <33.3ms drift for 30fps cameras or <16.7ms for 60fps ones. But I need a few hours for sync, transport and measure the latency, so I need maximum 10-30 ppm.

[unsigned_char_array]

---

@TTT wrote:

As solution, I thought about 2 identical boards and time sync between somepoint. Then, I will seperated and position them in front of camera and display that are actually far apart from each other. 

---

Can't you run a cable between them?

[Uwe Bonnes]

Any  two clocks will drift. Either run from the same clock or distribute a synchronization signal.

[Chris21]

"Would switching to:

External crystal (HSE)  
significantly reduce drift?"

-> Yes.

 

If necessary, consider a TCXO.

 

[TTT]

Do you have any suggestions for XO or TCXO?

[mƎALLEm]

Any crystal oscillator with MCU power supply range.

[unsigned_char_array]

Even with a low drift clock source I would calibrate the clocks. As the error of both clocks can be opposite so the differential error can be higher. Connect the boards to let them sync (let one board output a square wave and the other capture it). You can do this once and then save the calibration to non volatile memory. Since both modules likely have the same ambient temperature I think their differential drift will be minimal.

[CTapp.1]

Another option could be to use a GPS module with a sync pulse output - this will pulse once per second with an accuracy of 1uS (I think, but it's been a while since I've done this!).