SuperHouse / esp-open-rtos

Open source FreeRTOS-based ESP8266 software framework
BSD 3-Clause "New" or "Revised" License
1.54k stars 489 forks source link

sntp based time starts running backwards #767

Open HomeACcessoryKid opened 3 years ago

HomeACcessoryKid commented 3 years ago

I used the example of extras/sntp and then, based on a timer that triggers every second, collect a time_t=time(NULL) when 60 triggers have passed

This should give a constant update of near 1 minute in reported time which is does... HOWEVER, after a certain time (not always the same), the clock reports backwards by 7:44:50 (not always the same, but within a minute yes). It then continues going backward for an amount of time (not always the same*) and at that 'moment in the past' is starts reporting again 1 minute up until it goes back by 7:44:xx again and then gets back in gear

*) for one session (uninterrupted by a restart) the bad-run-time was 115 minutes twice, but another session it is much more. Is this based on a bug? there seems to be some repeatable pattern so it suggests a code based issue.

Any help is appreciated,

relevant pieces of code below

EXTRA_COMPONENTS = extras/sntp 

#define SNTP_SERVERS "0.pool.ntp.org", "1.pool.ntp.org", "2.pool.ntp.org", "3.pool.ntp.org"
void time_task(void *argv) {
    while (sdk_wifi_station_get_connect_status() != STATION_GOT_IP) vTaskDelay(20); 
    const char *servers[] = {SNTP_SERVERS};
    sntp_set_update_delay(24*60*60000); //SNTP will request an update every 24 hours
    const struct timezone tz = {1*60, 0}; //Set GMT+1 zone, daylight savings off
    sntp_initialize(&tz);
    sntp_set_servers(servers, sizeof(servers) / sizeof(char*)); //Servers must be configured right after initialization
    time_t ts;
    do {ts = time(NULL);
        if (ts == ((time_t)-1)) vTaskDelay(10);
    } while (!(ts>1608567890)); //Mon Dec 21 17:24:50 CET 2020
    printf("TIME: %ds %u=%s\n", ((unsigned int)ts)%86400, (unsigned int) ts, ctime(&ts));
    vTaskDelete(NULL); //check if NTP keeps running without this task
}

void heater1(uint32_t seconds) {
    time_t ts = time(NULL);
    char timestring[26]; ctime_r(&ts,timestring); timestring[19]=0;
    printf("Heater1 @ %d: S1avg=%2.4f S2avg=%2.4f %s", (seconds+10)/60, S1avg, S2avg, timestring+4\n);
}

TimerHandle_t xTimer;
void vTimerCallback( TimerHandle_t xTimer ) {
    uint32_t seconds = ( uint32_t ) pvTimerGetTimerID( xTimer );
    vTimerSetTimerID( xTimer, (void*)seconds+1); //136 year to loop
    if (seconds%60==50) {
        heater1(seconds);
    }
}

user_init:
    xTaskCreate(time_task,"Time", 512, NULL, 1, NULL);
    xTimer=xTimerCreate( "Timer", 1000/portTICK_PERIOD_MS, pdTRUE, (void*)0, vTimerCallback);

and a few lines of the output

Heater1 @ 346: S1avg=21.8750 S2avg=20.4792 Dec 23 22:29:27
Heater1 @ 347: S1avg=21.8750 S2avg=20.4896 Dec 23 22:30:28
Heater1 @ 348: S1avg=21.8750 S2avg=20.4896 Dec 23 22:31:28
Heater1 @ 349: S1avg=21.8646 S2avg=20.5000 Dec 23 07:03:05 <=double skip
Heater1 @ 350: S1avg=21.8750 S2avg=20.5000 Dec 22 23:19:24
Heater1 @ 351: S1avg=21.8750 S2avg=20.4896 Dec 22 15:35:42
Heater1 @ 352: S1avg=21.8750 S2avg=20.4792 Dec 22 07:52:01
Heater1 @ 353: S1avg=21.8750 S2avg=20.4792 Dec 22 00:08:20

maybe a conflict in multiple places where time gets defined?

#include <stdio.h>
#include <espressif/esp_wifi.h>
#include <espressif/esp_sta.h>
#include <espressif/esp_system.h> //for timestamp report only
#include <esp/uart.h>
#include <esp8266.h>
#include <FreeRTOS.h>
#include <task.h>
#include <semphr.h>
#include <timers.h>
#include <homekit/homekit.h>
#include <homekit/characteristics.h>
#include <string.h>
#include "lwip/api.h"
#include <udplogger.h>
#include "ds18b20/ds18b20.h"
#include "i2s_dma/i2s_dma.h"
#include "math.h"
#include <sntp.h>
HomeACcessoryKid commented 3 years ago

a friend also observed this kind of behaviour on an unrelated repository.
What they have in common is the use of CPU acceleration for specific activities. So for about 0.5 seconds at a time, the CPU goes to 160MHz and then back to 80MHz.

I switched to using extras/timekeeping which has a bit steeper learning curve, but performs perfect AFAIAConcerned If others bump into this, we might find a root cause in extras/sntp and solve it...

2Bcontinued