Counter API Delay Accuracy on Ambiq Apollo3 with Zephyr

[AlienSarlak]

I am facing an issue using the counter API for the Ambiq Apollo3. I have configured the device tree to use counter0 with clock source 2 (CTIMER_CTRL0_TMRA0CLK_HFRC_DIV16) and a frequency of 3 MHz. Theoretically, it should be possible to achieve an accuracy of approximately 334 ns. I used the counter sample code (Counter Sample Code) to implement a 10 µs delay, but the code does not work below 50 µs. However, delays of 50 µs and above work fine.

I would appreciate it if someone could shed light on this problem, whether it is a bug in Zephyr, an issue with the implementation of the Ambiq driver, or if I made a mistake in my configuration.

[AlienSarlak]

For the sake of completeness, below is my device tree:

/ {
    aliases {
        timer0 = &counter0;
        pin0 = &gpio17;
    };

    pin_gpio{
        compatible="gpio-leds";
        gpio17: gpio_17 {
			gpios = <&gpio0_31 17 GPIO_ACTIVE_HIGH>;
		};
    };
};

&counter0 {
    clock-frequency = <DT_FREQ_M(3)>;
    clk-source = <2>;
    status = "okay";
};

&gpio0_31 {
	status = "okay";
};

[ttmut]

Have you checked the output of counter_ticks_to_us and counter_us_to_ticks functions to see if the delay amount is calculated correctly?

It could also be that the relative alarm is too short and by the time the alarm is set it could already be expired. Some drivers implement a late detection algorithm to handle such situations.

[AlienSarlak]

I can confirm that the value for counter_us_to_ticks has been calculated as expected.

[AlienSarlak]

counter.c file :

void test_counter_interrupt_fn(const struct device *counter_dev,
                               uint8_t chan_id, uint32_t ticks,
                               void *user_data)
{
    struct user_data_struct *config = user_data;

    // struct counter_alarm_cfg alarm_config = config->alarm_cfg;
    struct gpio_dt_spec pin = config->gpio_dt_spec;

    int err;

    // toggle the GPIO
    if (gpio_pin_toggle_dt(&pin) < 0)
    {
        printk("GPIO could not be toggle!\n");
    }

    /* Set a new alarm with a same length duration */
    // alarm_config.ticks = alarm_config.ticks;

    err = counter_set_channel_alarm(counter_dev, chan_id, user_data);
    if (err != 0)
    {
        printk("Alarm could not be set\n");
    }
}

and the main.c file:

#include <zephyr/device.h>
#include <zephyr/sys/printk.h>
#include <counter.h>

// Delay in uS
#define DELAY 10
#define ALARM_CHANNEL_ID 0

#if defined(CONFIG_BOARD_APOLLO3_EVB)
#define TIMER DT_ALIAS(timer0)
#define PIN_GPIO DT_ALIAS(pin0)
#else
#error Unable to find a counter device node in devicetree
#endif

int main(void)
{
    // Hardware related devices
    const struct device *const counter_dev = DEVICE_DT_GET(TIMER);
    const struct gpio_dt_spec pin = GPIO_DT_SPEC_GET(PIN_GPIO, gpios);

    // User Data Struct
    struct user_data_struct user_data;

    int err = -EINVAL;

    // GPIO

    if (!gpio_is_ready_dt(&pin))
    {
        printk("device not ready.\n");
        return -ENODEV;
    }

    if (gpio_pin_configure_dt(&pin, GPIO_OUTPUT_ACTIVE) < 0)
    {
        printk("GPIO Configuration is not supported!\n");
        return 0;
    }

    //  GPIO

    printk("Counter alarm sample\n\n");

    if (!device_is_ready(counter_dev))
    {
        printk("device not ready.\n");
        return -ENODEV;
    }

    user_data.alarm_cfg.flags = COUNTER_ALARM_CFG_ABSOLUTE;
    user_data.alarm_cfg.ticks = counter_us_to_ticks(counter_dev, DELAY);
    user_data.alarm_cfg.callback = test_counter_interrupt_fn;
    user_data.gpio_dt_spec = pin;
    user_data.alarm_cfg.user_data = &user_data;

    // Free run mode
    err = counter_start(counter_dev);
    if (0 != err)
    {
        printk("counter_start Unknown Error %d\n", err);
    }
    /* Single shot alarm */
    err = counter_set_channel_alarm(counter_dev,
                                    ALARM_CHANNEL_ID,
                                    &user_data.alarm_cfg);
    if (-EINVAL == err)
    {
        printk("Alarm settings invalid\n");
    }
    else if (-ENOTSUP == err)
    {
        printk("Alarm setting request not supported\n");
    }
    else if (0 != err)
    {
        printk("Unknown Error\n");
    }

    while (1)
    {
        printk("tick = %d\n", user_data.alarm_cfg.ticks);
        printk("SLEEP FOREVER .... -_-\n");
        k_sleep(K_FOREVER);
    }
    return 0;
}

[ttmut]

You are using COUNTER_ALARM_CFG_ABSOLUTE flag so the driver is treating DELAY as an absolute value. Either use relative timing (.flags = 0) or set alarm ticks to current counter value plus delay value.

[AlienSarlak]

Thanks for your help I appreciate it. So, the tick value is treated as a relative delay from the current counter value if flag is set to 0.

Please give me 48 hours to check it first then if it works I can mark your reply as answer.

[AlienSarlak]

If I set the flag to zero instead of COUNTER_ALARM_CFG_ABSOLUTE, the system loses accuracy. For example, a duration of 50 µs increases to 73 µs, and a 10 µs duration still fails.
In the following you can see the signal when COUNTER_ALARM_CFG_ABSOLUTE is used (when delay is 50uS):

and below is when alarm_cfg.flags = 0;(when delay is 50uS):

On 10 µs there is no signal on both cases!

[AlienSarlak]

Based on my review of the Ambiq driver code, I observed the following implementation:

#if defined(CONFIG_SOC_SERIES_APOLLO3X)
    am_hal_ctimer_int_clear(AM_HAL_CTIMER_INT_TIMERA0C0);
    am_hal_ctimer_int_enable(AM_HAL_CTIMER_INT_TIMERA0C0);

    if ((alarm_cfg->flags & COUNTER_ALARM_CFG_ABSOLUTE) == 0) {
        am_hal_ctimer_compare_set(cfg->instance, AM_HAL_CTIMER_BOTH, 0, now + alarm_cfg->ticks);
    } else {
        am_hal_ctimer_compare_set(cfg->instance, AM_HAL_CTIMER_BOTH, 0, alarm_cfg->ticks);
    }
#endif

In this snippet, if the COUNTER_ALARM_CFG_ABSOLUTE flag is not set, the driver adds the current counter value (now) to alarm_cfg->ticks, hence treating the tick value as a relative delay. Conversely, if the flag is set to something else, it uses the value in alarm_cfg->ticks as an absolute counter value.

Given this behavior, my observation that a delay of 10 µs does not work as expected might be due to another factor in the system rather than the interpretation of the tick value.

I would appreciate any further insights or suggestions regarding this issue.

[ttmut]

It may be that the counter already counts past the target tick value, so it never triggers an alarm. You could try to read the counter value just after am_hal_ctimer_compare_set to see if the counter value is greater than the compare value.

[AlienSarlak]

Just before calling am_hal_ctimer_compare_set, the variable now is obtained by reading the current timer ticks using counter_ambiq_get_value(dev, &now). Consequently, the compare value is calculated as now + alarm_cfg->ticks. This makes sure that the timer is scheduled to trigger after the current counter value, preventing it from immediately passing the target tick value. This is my understanding based on the driver code.

[AlienSarlak]

I just realized that my callback function as an ISR won't be invoked if I set the delay below 20 µs, but I don't know why.

[AlienSarlak]

I have checked the driver code thoroughly, and it appears to be correct. However, whenever I configure the delay to 10 microseconds, the ISR does not trigger for reasons I do not fully understand.

As my experience with Zephyr is limited, I would greatly appreciate any guidance or suggestions on how to resolve this issue.