timerRead() is returning the last read value, not the actual

[EsserPrototyping]

Hardware:

Board: ESP32 doit
Core Installation version: 1.11.0
IDE name: Platform.io / VSCode

The value of timerRead() is not what it should be. It returns the value from the last read.
If i do three readings in a row, the third gets the first in the row next time i´m reading.

There is a timer runnning in the background (200000 micros) and in the loop im asking three times for the timer value every half second..

void loop() {
  
delay(499);

uint32_t loop_Timestamp = (unsigned long)esp_timer_get_time();  
uint32_t loopTSP = loop_Timestamp-(unsigned long)MIT_Timestamp;
  
// uint32_t blindTRM0 = (unsigned long)timerRead(MAIN_ISR_TIMER);   // "blind" READ

uint32_t tRM1 = (unsigned long)timerRead(MAIN_ISR_TIMER); 
uint32_t tRM2 = (unsigned long)timerRead(MAIN_ISR_TIMER);
uint32_t tRM3 = (unsigned long)timerRead(MAIN_ISR_TIMER);
  
Serial.print(" TSP ");  Serial.print(loopTSP);
Serial.print("   TR1 ");  Serial.print(tRM1);  
Serial.print("   TR2 ");  Serial.print(tRM2);        
Serial.print("   TR3 ");  Serial.println(tRM3);
}

without "blind" read:

Debug Messages:

TIMESTAMP	READING 1	READING 2	READING 3

TSP 25288   	TR1 126291   	TR2 25291   	TR3 25291
TSP 124288   	TR1 25291   	TR2 124291   	TR3 124291
TSP 23288   	TR1 124291   	TR2 23291   	TR3 23291
TSP 122288   	TR1 23291   	TR2 122291   	TR3 122291
TSP 21288   	TR1 122291   	TR2 21291   	TR3 21291

If i read the value four times and only print the the last three readings it is right..
with "blind" read:

Debug Messages:

TSP 83378   	TR1 83381   	TR2 83381   	TR3 83381
TSP 182378   	TR1 182381   	TR2 182381   	TR3 182381
TSP 81378   	TR1 81381   	TR2 81381   	TR3 81381
TSP 180378   	TR1 180381   	TR2 180381   	TR3 180381
TSP 79378   	TR1 79381   	TR2 79381   	TR3 79381

[EsserPrototyping]

I think i got deeper to the root of the problem..

In the esp32-hal-timer.c the timerRead functions as followed:

uint64_t timerRead(hw_timer_t *timer){
    timer->dev->update = 1;
    uint64_t h = timer->dev->cnt_high;  
    uint64_t l = timer->dev->cnt_low;
    return (h << 32) | l;
}

If i put a 1ms delay after the update, it seems to update the register fast enough, so the returned value is right.

uint64_t timerRead(hw_timer_t *timer){
    timer->dev->update = 1;  
    delay(1); 
    uint64_t h = timer->dev->cnt_high;  
    uint64_t l = timer->dev->cnt_low;
    return (h << 32) | l;
}

The only practical solutions are to "blind" read once before using the value, or to get a timestamp in the ISR, (pass it in a Task to an usable variable outside the ISR) and compare it against the actual time with esp_timer_get_time().

[mkovero]

I second this, timerRead() is broken and blind reads help.

[stale]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[EsserPrototyping]

Is there another option for reporting bugs? It doesn’t seemed to be recognized by espressif.

[stale]

[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future.

[atanisoft]

@EsserPrototyping well, this is a community supported project. Feel free to submit a PR to fix the incorrect behavior. However, using delay() inside the ISR is not likely to be accepted as that can have unintended consequences with the watchdog timer being triggered.

[EsserPrototyping]

Ok, thanks. This wasn´t ment to sound like a complaint. I´m not able to fix this and I know that the delay() is no fix too. I just thought there´s maybe a list of known bugs or something like that.

[atanisoft]

This may not be a heavily used area of code and that might explain the issue you are seeing. Many people don't understand the proper way to use the hardware timers and end up causing themselves a lot of problems and thus often it is suggested to try the Ticker library for periodic tasks instead.

Is there a specific reason you are trying to read the timer value?

[stale]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[stale]

[STALE_DEL] This stale issue has been automatically closed. Thank you for your contributions.