Hardware timers drift

[limerickcabin]

In esp32-hal-timer.c, commenting out the reloading of the timer corrects a few microsecond drift per interrupt:

void IRAM_ATTR __timerISR(void * arg){
uint32_t s0 = TIMERG0.int_st_timers.val;
uint32_t s1 = TIMERG1.int_st_timers.val;
TIMERG0.int_clr_timers.val = s0;
TIMERG1.int_clr_timers.val = s1;
uint8_t status = (s1 & 3) << 2 | (s0 & 3);
uint8_t i = 4;
//restart the timers that should autoreload
while(i--){
hw_timer_reg_t * dev = hw_timer[i].dev;
if((status & (1 << i)) && dev->config.autoreload){
//do not reload timer - HW has done so already
//dev->load_high = 0;
//dev->load_low = 0;
//dev->reload = 1;
dev->config.alarm_en = 1;
}
}
i = 4;
//call callbacks
while(i--){
if(status & (1 << i)){
if(__timerInterruptHandlers[i]){
__timerInterruptHandlersi;
}
}
}
}

[me-no-dev]

interesting... I had tried and tried this when I was writing the driver and could not get it to autoreload... that is why that code is there. Will retest again and remove :)

[limerickcabin]

I think the real culprit is the dev->reload = 1; line which does a software reload of the timer some microseconds after the hardware timer already set it to 0 hence losing a few microseconds. I only noticed it when I increased the interrupt rate to 8000 hz (125 microseconds). I did have to leave the dev->config.alarm_en = 1; line which surprised me after reading the spec sheet. I wouldn't have expected to have to reset that bit each time but you do to get it to autoreload after the first.