cancel
Showing results for 
Search instead for 
Did you mean: 

Time Drift Between 2 Identical Black Pill boards

TTT
Associate II

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.

5d2c9cdb-8dc7-422e-b9cc-81b2d7b0c9cd.jpg
512df020-aea1-461d-8c5f-6a1cc51f3b32.jpg1f60dc85-8974-4544-8f67-6971d84baa8d.jpg

 

1 ACCEPTED SOLUTION

Accepted Solutions
Uwe Bonnes
Chief

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

View solution in original post

14 REPLIES 14
mfgkw
Senior III

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
ST Employee

Hello @TTT and welcome to the ST community,

Did you refer to the datasheet?:

mALLEm_0-1770911936226.png

mALLEm_0-1770912050220.png

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.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

Thank you for your interest,

TTT_0-1770912442650.png

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

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.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

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

Kudo posts if you have the same problem and kudo replies if the solution works.
Click "Accept as Solution" if a reply solved your problem. If no solution was posted please answer with your own.
Uwe Bonnes
Chief

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

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.

Chris21
Senior III

"Would switching to:

External crystal (HSE)  
significantly reduce drift?"

-> Yes.

 

If necessary, consider a TCXO.

 


@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?

Kudo posts if you have the same problem and kudo replies if the solution works.
Click "Accept as Solution" if a reply solved your problem. If no solution was posted please answer with your own.