Ok, la pregunta original pedía métodos, no la causa raíz, que daré aquí.

Pero no me gusta dejar la pregunta sin responder. Sin faltarle el respeto a todas las sugerencias finas que he recibido. Gracias a todos los que han contribuido a que finalmente podamos resolver esto.

Todo fue mucho mejor después de que nos dimos cuenta de que el problema estaba relacionado con la configuración de la hora en octubre, en lugar de un error desconocido en diciembre.

El culpable fue un error en la codificación de INT a BCD del valor del mes, donde el autor original agregó erróneamente 1 al valor codificado de BCD, en lugar del valor de INT antes de codificarlo; lo que hace que octubre se envíe al RTC como 0x0A, en lugar de 0x10.

El reloj pasa alegremente de 0x0A a 0x0B al entrar en noviembre, y la rutina de BCD a INT no fue demasiado exigente para obtener valores BCD no válidos. Todavía tiene el derecho 0x0B (BCD 0x0B a INT = 0x0B, sin embargo, 0x0B no es un valor BCD válido ...).

Todavía no he confirmado cómo terminamos en abril, eso todavía está en mi TODO para esto.

Sin embargo, estoy bastante seguro de que finalmente estoy en la verdadera causa raíz de este problema.

@Kellenjb: y tenías razón, también: fue un error de firmware :)

Actualizar

Bien, ahora he confirmado que cuando el DS1305 pasa del valor de mes 0x0A no válido (octubre), termina con 0x0B para noviembre. Con una implementación ingenua de BCD a INT (una que no comprueba la validez de la entrada BCD), BCD 0x0B == INT 0x0B, por lo que todavía funciona.

Es cuando el DS1305 está incrementando 0x0B (al ver 0x0A ir a 0x0B, uno podría esperar 0x0C, pero no) termina con 0x04 al entrar Diciembre.

• Si tiene un depurador que es capaz de detenerse cuando hay un acceso de memoria a una dirección particular, puede ser una buena idea establecer eso y ver si hay un acceso no deseado de color rojo. Puede que tengas que dejar el sistema encendido por un tiempo. He tenido el placer de lidiar con los cuadros apilados solo un poco por encima de su límite causando problemas de nervios.

• Si no tiene el anterior, puede colocar un analizador SPI (analizador lógico) y capturar el tráfico durante algún tiempo, esto le dará una muy buena idea de lo que puede estar sucediendo.

• También intentaría empujar un pico de potencia que pasa 5 V y por debajo de 2,5 V (condición de funcionamiento nominal) y ver si el problema está regresando.

• Miraría el problema en el otro lado, es decir, la CPU, tal vez, su SPI tiene un problema, busque los problemas de SPI con el procesador en particular que tiene. Es casi siempre el lugar menos esperado.

¿Cómo está procesando el código el tiempo del RTC? ¿El 'resbalón' es precisamente nueve meses (de modo que la hora del día es correcta)? ¿Tiene alguna idea de cuándo fue la última vez que se encuestó el reloj antes del retroceso y la primera vez que se encuestó después? ¿Cuál es el patrón para leer la fecha / hora? ¿Se lee como una transacción única de siete bytes que comienza con el registro cero?

Parece curioso que un sistema con meses BCD se deslice de 0x11 o 0x12 a 0x04. Sé que algunos chips RTC podrían tener algunas interacciones extrañas entre las actualizaciones de lectura y registro, aunque el chip DS dice que copia la hora / fecha en registros estáticos antes de una lectura. Algunos chips tienen una peculiaridad molesta en la que una lectura que tarda demasiado tiempo podría hacer que el reloj pierda tiempo (supongo que sería más bien que duplicar los bits superiores, simplemente aplazan los incrementos mientras se realiza una lectura; si el incremento aún se aplaza cuando llegue el momento de otro, se perderá el último incremento) pero dudo que algo así pueda estar sucediendo aquí, a menos que la última operación de lectura fuera en abril y la primera lectura errónea en noviembre.

Addendum

¿El código está realizando alguna conversión de datos en el momento desde el chip (es decir, si el código mismo almacena el tiempo como YYYY-MM-DD HH: MM: SS, o el número de segundos desde la medianoche GMT del 1 de enero de 1970, o ¿Qué?) ¿Cómo se maneja el horario de verano? Bajo las viejas reglas de DST, si el DST se maneja configurando el RTC hacia adelante y hacia atrás (como se hace en algunos sistemas, incluidos los PC, pero parece realmente tonto), podría fácilmente predecir posibles problemas si un dispositivo se apagara mientras el DST estaba activo. y se encendió entre las 11:00 pm y las 11:59 el 31 de octubre (que se almacenaría en el RTC como horas entre la medianoche y las 12:59 am del 1 de noviembre). También podría imaginar algunos casos extraños de esquina al intentar convertir YYYY-MM-DD HH: MM: SS en algo así como segundos lineales cuando se ejecuta el código en una CPU de 8 bits, si uno intentara usar una combinación optimizada de 16 y 32 -bate las matemáticas pero no hizo las cosas bien, pero el resbalón de tiempo sería probablemente un múltiplo de poder de dos de algún tipo de unidades, lo que no parece ser el caso aquí.

Esto indica lo obvio, pero ¿ha revisado los números de lote de los IC en los dispositivos con problemas para ver si provienen de diferentes lotes en la fundición de las cajas que no presentan los síntomas?

¿También se obtuvieron todos sus circuitos integrados en el mismo envío del fabricante o algunos de pedidos diferentes? ¿Alguna correlación entre órdenes y fallos?

¿Alguno de los circuitos integrados proviene del "mercado gris"? ¿Existe la posibilidad de que tenga algunos chips falsificados o cuestionables mezclados con los buenos?

Finalmente, ¿existe alguna correlación entre los dispositivos defectuosos y su proceso de fabricación? ¿Se hicieron todos los dispositivos defectuosos en la misma semana o todos los viernes, por ejemplo?