STM32C091CCT6 – Timer period measured ~995 ms instead of configured 1000 ms using HSI @ 48 MHz

[Sandeep.nandwana]

We are using an STM32C091CCT6 with the internal HSI (48 MHz) configured as the system clock.

Our application generates a volume-based pulse output using TIM14 in one-shot compare mode. The output pulse frequency is derived from flow rate, and the receiving equipment measures the number of pulses generated per second. Therefore, maintaining an accurate 1-second timing window is important for correct pulse frequency and flow indication.

Timer Configuration

• MCU: STM32C091CCT6
• Clock source: Internal HSI (48 MHz)
• SYSCLK: 48 MHz
• TIM14 clock: 48 MHz
• Prescaler: 47
• Timer resolution: 1 µs per tick
• Pulse window: 1,000,000 timer ticks (expected = 1000 ms)

Observation

When measuring the pulse window using a logic analyser, we consistently observe the following:

• Expected pulse window: 1000 ms
• Measured pulse window: ~995 ms
• Timing error: approximately 0.5%

This timing difference directly affects the pulse-per-second measurement used by downstream equipment.

Current Workaround

To compensate for the observed timing difference, we increased the pulse window by approximately 5000 ppm:

• Original window: 1,000,000 ticks
• Compensated window: 1,005,000 ticks

This produces a measured pulse window very close to 1000 ms.

Questions

1. Is an observed timing error of approximately 0.5% expected when using the STM32C091 internal HSI oscillator?
2. Does the factory calibration tolerance of the HSI explain this level of timing deviation?
3. For applications requiring accurate pulse-per-second timing, what is the recommended approach?
   • HSI trimming or calibration
   • Runtime compensation
   • Using an external HSE crystal/oscillator
   • Another recommended method
4. Is compensating the timer window (approximately +5000 ppm) an acceptable long-term solution, or is there a better approach recommended by ST?

We would appreciate your guidance on the recommended method for achieving accurate timer-based pulse generation using the STM32C091 series.

Thank you.

[Andrew Neil]

• Clock source: Internal HSI (48 MHz)

So what is the accuracy spec on that ?

Have you measured the actual frequency?

 

PS:

https://www.st.com/resource/en/datasheet/stm32c091cc.pdf#page=66

[AScha.3]

>For applications requiring accurate pulse-per-second timing, what is the recommended approach?

 

Always standard: real crystal has to be the source , or mems with similar 20ppm tolerance. → 

• Using an external HSE crystal/oscillator

[Sandeep.nandwana]

Thank you both for the feedback.

We have checked the HSI48 specification and performed timing measurements on our STM32C091CCT6 hardware.

1. What is the HSI48 accuracy specification?

Our understanding from the STM32C091CCT6 datasheet is that HSI48 is a nominal 48 MHz internal RC oscillator, with its accuracy depending on VDD and temperature.

At VDD = 3.0 V and TA = 30 °C, the datasheet specifies/characterises HSI48 around:

• Minimum: 47.92 MHz

• Nominal: 48 MHz

• Maximum: 48.40 MHz

The datasheet also specifies approximately ±1% variation over the 0 °C to 85 °C range, with wider variation over the extended temperature range.

Therefore, an approximately +0.5% deviation is within the expected HSI48 operating characteristics.

2. Have you measured the actual frequency?

Yes, we have measured the timing externally using a logic analyser.

Our TIM14 configuration is:

• SYSCLK = HSI48, nominal 48 MHz

• TIM14 clock = 48 MHz nominal

• Prescaler = 47

• Timer frequency = 48 MHz / 48 = 1 MHz

• Timer resolution = 1 µs

• Pulse window = 1,000,000 ticks

Ideally:

1,000,000 ticks = 1000 ms

However, on our hardware we measure approximately:

995 ms

From this measurement, the effective clock frequency is approximately:

48 MHz × (1000 / 995) ≈ 48.24 MHz

This corresponds to approximately +0.5% / +5000 ppm relative to the nominal 48 MHz.

So this is an indirect measurement of the effective HSI/timer clock using an external time reference. We have not yet measured the HSI frequency directly using a frequency counter/reference.

3. What happens with software compensation?

As a temporary solution, we compensate the pulse scheduling window by approximately +5000 ppm.

Instead of:

1,000,000 ticks

we use:

1,005,000 ticks

With this compensation, the measured pulse window becomes approximately the following:

1000 ms / 1 second

on our tested hardware.

So the compensation successfully corrects the observed timing error on this particular board.

However, we understand that a fixed +5000 ppm correction may not be suitable for every MCU because HSI accuracy can vary with device, VDD and temperature.

4. What is the application requirement?

Our application is a flow meter, and the pulse output represents measured volume.

The external system counts these pulses to determine the transferred volume/flow. Therefore, accurate and stable pulse timing is important.

In particular, we need the generated pulse timing to remain accurate over time rather than having a systematic approximately 0.5% timing error.

5. For applications requiring accurate pulse-per-second timing, what is the recommended approach?

Based on the feedback provided, our understanding is that HSI48 should not be considered the preferred clock source when accurate pulse-per-second timing is required.

For this type of application, the recommended approach is to use an external HSE crystal or oscillator or another accurate reference such as a MEMS oscillator with suitable ppm accuracy.

We would therefore like to confirm with ST whether this is the recommended architecture for our flow-meter application.

6. Is HSI trimming or runtime calibration recommended?

Could ST please advise whether HSI48 trimming/calibration can provide sufficient accuracy for our application over the following:

• MCU-to-MCU production variation

• VDD variation

• Temperature variation

• Long-term operation

If HSI calibration is recommended, we would also appreciate the recommended ST calibration procedure and reference method.

7. Is our +5000 ppm software compensation acceptable?

For the current prototype, the +5000 ppm compensation gives us approximately 1 second from a nominal 1,000,000-tick window:

Parameter	Result
Nominal HSI	48 MHz
TIM14 prescaler	47
Nominal timer tick	1 µs
Nominal window	1,000,000 ticks
Measured window	~995 ms
Estimated error	~+0.5%
Compensated window	1,005,000 ticks
Measured compensated window	~1000 ms

However, we consider this a board-level compensation/calibration, not a replacement for an accurate clock reference.

For production, our current understanding is that using an external HSE crystal/oscillator with suitable ppm accuracy would be the more robust solution for accurate pulse timing.

Questions for ST

Could you please confirm the following?

1. Is the approximately +0.5% HSI48 deviation we measured within the expected STM32C091CCT6 HSI48 behaviour?

2. Is there a recommended way to directly measure/calibrate HSI48 during production?

3. Can HSI trimming provide the required pulse timing accuracy over temperature and VDD variation?

4. For applications requiring accurate pulse-per-second timing, does ST recommend using an external HSE crystal/oscillator instead of HSI48?

5. If HSE is recommended, would a 10–20 ppm crystal/oscillator be an appropriate accuracy target for this application?

6. Is there any ST-recommended alternative to HSE that can provide comparable timing accuracy?

Thank you for confirming the recommended approach.

[Andrew Neil]

2. Have you measured the actual frequency?

Yes, we have measured the timing externally using a logic analyser.

So you have not actually measured the HSI frequency.

Route the HSI to an MCO pin, and measure it directly:

 

[Sandeep.nandwana]

We measured the HSI48 directly through the MCO output on PF2.

The oscilloscope shows approximately 47.61 MHz versus the nominal 48 MHz, which is about −0.81% (−8,125 ppm).

Attached is the oscilloscope screenshot for reference.

We are also checking the RCC/TIM14 clock path against our earlier ~995 ms measurement before drawing a conclusion about the timer error.
 

 

[Gyessine]

Hello ​@Sandeep.nandwana 
Just a quick question 
what sampling rate are you using in the logic analyzer? 
make sure it’s the maximum of 500MS/s
BR
Gyessine

[Sandeep.nandwana]

Hi Gyessine,

Thank you for the suggestion. We have checked the timing both with the logic analyzer and directly with the oscilloscope.

With the logic analyzer, the nominal 1000 ms window is measured around 995 ms. We also verified the timing on the oscilloscope.

With the software compensation set to 1,005,000 µs, the measured window is now approximately 1 second accurately.

We will also verify the logic-analyzer measurement at the recommended 500 MS/s sampling rate.

[TDK]

You don’t mention your requirements anywhere, but if 0.5% is not acceptable, the HSI will not be acceptable for you unless you calibrate for each chip and temperature range.

A standalone crystal is a much better choice.

[Gyessine]

Hello ​@Sandeep.nandwana 

All probable issues and the most common fixes are already mentioned by other users.

If accuracy is required, use a HSE clock.

However, based on the description, the constant drift seems unusual. If the description is correct, the drift is nearly 5000 ppm and constant.

In typical cases, HSI clock inaccuracy varies in both directions and across pulses and this is what will make me consider another root cause even though it’s a low probability
BR
Gyessine