Zephyr Counter Driver Limitations for Short Delay Generation on Ambiq Apollo3 EVB #87539
Labels
area: Counter
bug
The issue is a bug, or the PR is fixing a bug
platform: Ambiq
Ambiq
priority: low
Low impact/importance bug
An issue has been identified with the use of the Zephyr counter API on the Ambiq Apollo3 microcontroller. When configuring counter0 with clock source 2
CTIMER_CTRL0_TMRA0CLK_HFRC_DIV16
, which yields a timer frequency of 3 MHz, the expected timing resolution should be approximately 334 ns. However, attempts to generate short delays using the standard Zephyr counter sample code revealed that the (ISR) is not invoked for delays shorter than approximately 10 µs. This behavior limits the ability to achieve fine-grained timing control, and the underlying cause of this limitation remains unknown to me.What target platform are you using?
What have you tried to diagnose or workaround this issue?
Furthermore, I observed that setting
alarm_cfg.flags = 0
results in deteriorated timing accuracy, while usingCOUNTER_ALARM_CFG_ABSOLUTE
leads to improved precision for delays greater than 50 µs. This result was unexpected, as the default relative alarm mode was initially assumed to provide better accuracy.To Reproduce
apollo3_evb.overlay:
code: https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/drivers/counter/alarm
modify main.c as:
prj.conf
Expected behavior
With a 3 MHz timer (334 ns resolution), the counter should generate accurate delays. A configured delay of 10 µs should produce a 10 µs pulse, and a 5 µs delay should result in a 5 µs pulse. This precision is expected given the hardware capabilities and timer resolution.
Impact
The lack of precise timing support has effectively blocked further development of my project.
Environment
Additional context


Delay of 50 µs when using
alarm_cfg.flags = COUNTER_ALARM_CFG_ABSOLUTE;
Delay of 50 µs when using
alarm_cfg.flags = 0;
The text was updated successfully, but these errors were encountered: