ESP32 Forum

Posted: **Thu Sep 07, 2023 11:18 am**

Dear all,
currently I implement software for ESP32 which frequently calls `int64_t current_time = esp_timer_get_time()`. Each time I check if `current_time - last_updated > INTERVAL`, where `last_updated` is a 64 bit signed integer. Since the ESP32 is a 32 bit processor, there are no 64 bit atomics, thus the compiler generates code which uses at least two instructions for reading esp_timer_get_time() into the variable `current_time` or into whatever memory area the compiler decides -- those instructions potentially could be interrupted by a timer interrupt. This leads to undefined behavior and thus is highly dangerous for my software, which relies on correct timing. Even though this is highly unlikely to happen, the chance is still not zero. I cannot take this risk.

How do I avoid such? One classic approach would be to use a mutex or similar locking mechanism, but I don't have access to the timer interrupt incrementing the underlying timer variable, so I can't prepend a lock and append an unlock.

Do you have any idea to make esp_timer_get_time() thread-safe?

Best, chris

Posted: **Thu Sep 07, 2023 12:51 pm**

esp_timer_get_time() takes care of this internally.

Posted: **Thu Sep 07, 2023 1:00 pm**

Thank you alot, I wasn't aware of this. I see why this gives a consistent reading of the counter value. But this function call potentially never terminates. Is this something I just have to accept?

Posted: **Thu Sep 07, 2023 2:24 pm**

chris20601 wrote: ↑
Thu Sep 07, 2023 1:00 pm
Thank you alot, I wasn't aware of this. I see why this gives a consistent reading of the counter value. But this function call potentially never terminates. Is this something I just have to accept?

I'd make the point that if your CPU gets interrupted so often that it can't access two simple register reads without being interrupted, you have more important issues to worry about.

Posted: **Fri Sep 08, 2023 6:41 am**

chris20601 wrote: ↑
Thu Sep 07, 2023 1:00 pm
Is this something I just have to accept?

Either that, or you implement your own 'deterministic' version of the function:

Code: Select all

    uint32_t lo1, lo2, hi;
    /* Set the "update" bit and wait for acknowledgment */
    systimer_ll_counter_snapshot(hal->dev, counter_id);
    while (!systimer_ll_is_counter_value_valid(hal->dev, counter_id));
    
    lo1 = systimer_ll_get_counter_value_low(hal->dev, counter_id);
    hi = systimer_ll_get_counter_value_high(hal->dev, counter_id);
    lo2 = systimer_ll_get_counter_value_low(hal->dev, counter_id);
    
    if( lo2 < lo1) {
      // An overflow happened in the low register; adjust hi
      hi += 1;
    }

    systimer_counter_value_t result = {
        .lo = lo2,
        .hi = hi
    };

    return result.val;

(This assumes that the timer's value only ever increments by less than 1<<32 between the calls to systimer_ll_get_counter_value_low, i.e. no arbitrary adjustments from the application; which should be the case for the "system" timer.)

ESP32 Forum

Thread/interrupt-safeness of esp_timer_get_time

Thread/interrupt-safeness of esp_timer_get_time

Re: Thread/interrupt-safeness of esp_timer_get_time

Re: Thread/interrupt-safeness of esp_timer_get_time

Re: Thread/interrupt-safeness of esp_timer_get_time

Re: Thread/interrupt-safeness of esp_timer_get_time