What should a firmware timing specification contain?
A useful timing specification records the selected MCU, clock source, required interval, acceptable error, execution deadline and recovery behavior. A register calculation answers only part of that specification. Keep the numerical result, its assumptions and the tests that will validate it together.
Two separate examples illustrate the distinction below: Cortex-M4 SysTick periodic reload and STM32G0 independent watchdog timeout. They are different hardware scopes; this article does not imply that STM32G0 uses a Cortex-M4 core.
Example 1: Cortex-M4 SysTick periodic reload
For the periodic counter model, an interval of N timer clocks uses RELOAD = N − 1. The scoped calculator selects N by rounding the timer-clock frequency divided by the requested tick frequency. This rounding is a calculator policy. Its accepted periodic range is N = 2 through 16,777,216. Supply the actual SysTick input clock rather than assuming it equals the CPU clock. ST PM0214, Rev 10, section 4.5.2.
As a worked arithmetic example, a 16 MHz timer clock and a requested 1 kHz tick give N = 16,000 and RELOAD = 15,999. The resulting nominal interval is 1 ms. This is a counter setting, not a measurement of task response time.
For a project specification, record the selected clock and its operating modes alongside the requested and calculated tick rates. Then define a separate acceptance test for the application deadline. This separates a reproducible calculation from a system-level performance claim.
Example 2: STM32G0 independent watchdog
For the scoped nominal STM32G0 IWDG model, timeout = (reload + 1) × prescaler / LSI frequency. A reload of 999, prescaler of 32 and assumed LSI frequency of 32 kHz produce a nominal one-second interval. Actual timing depends on the oscillator frequency; use the selected part’s documentation to establish the frequency bounds. ST STM32G0 IWDG training, page 10.
A planning worksheet can carry both the nominal result and an interval calculated from the applicable minimum and maximum clock frequencies. Do not substitute a nominal one-second estimate for a guaranteed one-second recovery requirement.
Requirements to agree before implementation
Use this checklist as a project discussion aid:
- Identify the exact MCU part, documentation revisions and firmware version.
- Record the timer clock source, frequency assumptions and changes between operating modes.
- Specify the required tick rate, acceptable rounding error and application deadline separately.
- Define which completed application checks permit a watchdog refresh.
- Document the longest intended operation that may delay a refresh, including its acceptance limit.
- Describe the expected startup and recovery behavior after a reset.
- List the measurements, fault scenarios and environmental conditions needed for acceptance.
For each item, assign an owner and keep the evidence with the release record. If a requirement remains unknown, label it unresolved instead of filling it with an assumed value.
Frequently asked questions
Does an exact calculated tick rate prove the firmware meets its deadline?
No. Treat the counter calculation and the application timing acceptance test as separate deliverables. The calculation records the intended interval; the test supplies evidence about the implemented system.
Can the watchdog example be copied to every STM32 family?
No. The example is scoped to the STM32G0 IWDG training document. Review the selected device’s registers, clock limits and operating behavior before applying a configuration.
What should be included when requesting a firmware review?
Provide the MCU part number, clock configuration, timing requirements, refresh policy, reset observations and available test evidence. Mark missing information explicitly so the review can distinguish known results from assumptions.
Discuss the project requirements
See STM32 development services for the existing service overview, or contact InnovChip with the requirements worksheet and project scope.