Estoy escribiendo un firmware para CC3220SF desde TI utilizando una placa personalizada que he diseñado. Me enfrento a un comportamiento extraño y no estoy seguro de si se trata de hardware o firmware relacionado.
Aquí estoy buscando algunos consejos sobre cómo investigar más en esta situación.
Básicamente, mi aplicación sigue este patrón:
- se despierta de la hibernación
- lee el RTC interno
- adquiere algunos sensores
- los envía a una nube
- vuelva a leer el RTC si es necesario
- vuelve a hibernar
nada nuevo, lo sé. El problema es que, a veces, las lecturas de RTC son incorrectas. Con "incorrecto" me refiero a que durante las llamadas subsiguientes (incluso en la misma ventana activa) los valores de lectura están en el futuro (es decir, 2022), pero luego vuelven a los correctos.
Un ejemplo de mis registros:
[SYS] SlDateTime_t: 2017/11/28 23:16:5
[SYS] struct tm: 117/10/28 23:16:5
[SYS] time_t : 1511910965
...
[SYS] SlDateTime_t: 2022/3/1 9:58:17
[SYS] struct tm: 122/2/1 9:58:17
[SYS] time_t : 1646128697
...
[SYS] SlDateTime_t: 2017/11/28 23:16:9
[SYS] struct tm: 117/10/28 23:16:9
[SYS] time_t : 1511910969
aquí el código que estoy usando para probarlo:
time_t _GetEpoch(void)
{
_i16 ret;
_u8 pConfigOpt = SL_DEVICE_GENERAL_DATE_TIME;
_u16 pConfigLen = sizeof(SlDateTime_t);
SlDateTime_t dateTime = {0};
ret = sl_DeviceGet(SL_DEVICE_GENERAL, &pConfigOpt, &pConfigLen, (unsigned char *) &dateTime);
ASSERT_ON_ERROR(ret);
struct tm t;
time_t t_of_day;
t.tm_year = dateTime.tm_year - 1900;
t.tm_mon = dateTime.tm_mon - 1;
t.tm_mday = dateTime.tm_day;
t.tm_hour = dateTime.tm_hour;
t.tm_min = dateTime.tm_min;
t.tm_sec = dateTime.tm_sec;
t.tm_isdst = -1;
t_of_day = mktime(&t);
UART_PRINT("[SYS] SlDateTime_t: %d/%d/%d %d:%d:%d\r\n", dateTime.tm_year, dateTime.tm_mon, dateTime.tm_day, dateTime.tm_hour, dateTime.tm_min, dateTime.tm_sec);
UART_PRINT("[SYS] struct tm: %d/%d/%d %d:%d:%d\r\n", t.tm_year, t.tm_mon, t.tm_mday, t.tm_hour, t.tm_min, t.tm_sec);
UART_PRINT("[SYS] time_t : %lld\r\n", t_of_day);
return t_of_day;
}
Mis pensamientos:
- Estoy afirmando contra los errores devueltos por
sl_DeviceGet(), por lo tanto, la función se ejecuta correctamente - en los registros, verá que el error está en la estructura
SlDateTime_tque devuelve la funciónsl_DeviceGet(), por lo tanto, no está relacionado conmktimeo mi otra parte del código - por otro lado, si la próxima lectura es correcta, no parece ser un problema de hardware porque esperaría una corrupción de los valores también en las siguientes lecturas. En su lugar son correctos.
La última prueba fue un bucle infinito donde leí 100 veces el RTC, luego fui a la hibernación y otra vez. Los resultados confirmaron que una lectura entre 100 es incorrecta. ¡Los otros son correctos!
ACTUALIZACIÓN
Después de desconcertarme un poco, descubrí lo siguiente:
- con el código de prueba obtuve 250 valores incorrectos en lecturas de menos de 60k
- la diferencia entre un valor incorrecto y la lectura inmediatamente anterior o siguiente es siempre 134.217.728 segundos en el futuro.