Problema del reloj en tiempo real con PIC18F87K22

1

Estoy trabajando en un diseño de placa relativamente simple con un procesador PIC18F87K22. Pasa la mayor parte de su tiempo dormido, despertándose para enviar una alerta a través de un módulo celular incorporado cuando hay una interrupción externa, o cuando se activa como un registro programado por el reloj en tiempo real. Está usando un oscilador externo (CM200C32768DZFT) para manejar el reloj en tiempo real, y estoy notando algún comportamiento extraño ocasional.

Específicamente, estoy notando que el check-in programado se activa con mucha más frecuencia de lo esperado, o en ocasiones con mucha menos frecuencia. Estoy enviando el estado actual del reloj junto con el paquete de celdas, para que pueda ver que el dispositivo aparentemente se ha incrementado en 60 minutos, aunque haya pasado mucho menos tiempo de lo que ha pasado. No se apaga por un factor consistente (y, como se señaló anteriormente, a veces puede ser rápido o lento), y solo lo he visto afectando a algunos de los dispositivos; Otros que son aparentemente idénticos parecen funcionar bien. Además, es un problema que solo apareció cuando comenzamos a realizar pruebas en el exterior en climas fríos (el dispositivo está diseñado para funcionar en exteriores). Poner dentro de uno de los dispositivos afectados y dejar que se caliente parece resolver el problema. Sin embargo, no hemos podido replicar el problema en interiores bajo condiciones controladas, incluso en un congelador que alcanza las mismas bajas temperaturas a las que el dispositivo estuvo expuesto al exterior.

Por lo tanto, un problema que solo aparece a veces, solo para algunos dispositivos y no para otros, y solo en ciertas condiciones ambientales ciertamente parece apuntar a un problema de producción de hardware. Pero la tasa de fallos es más alta de lo que esperaba, y cuando intentamos cambiar el oscilador en una de las tablas afectadas por otra que sabíamos que estaba funcionando, el problema se mantuvo en la placa, no en el oscilador. Adjunto la parte relevante del esquema y el diseño del tablero. Tal vez haya algo que esté haciendo mal con la conexión al oscilador, tal vez el mismo oscilador deba reemplazarse con un componente diferente, tal vez haya algo obvio en el que no esté pensando en el diseño del circuito que pueda causar un problema intermitente como este . Me encantaría recibir recomendaciones o sugerencias.

Editadoparaagregar:

Hmm,ytalvezestoybuscandoenellugarequivocadolafuentedelproblema.Hayotroosciladorenlaplaca(FOXSDLF/160-20),atadoalospines49y50,talvezesasealaentradaprincipaldelreloj.Eseestáconectadoatierracon2condensadoresde22pF.Seguiréinvestigandomás,perocualquiercomentarioosugerenciaadicionalseríabienvenido.

Editar para agregar más:

No, creo que tenía razón la primera vez. X1 es el oscilador principal, que se usa para configurar la frecuencia del procesador principal cuando se alimenta. X3 es el oscilador secundario, que se utiliza para controlar el RTC incluso cuando el procesador está inactivo, y se utiliza para controlar las interrupciones basadas en RTC.

    
pregunta Grey

1 respuesta

1

¿Microchip recomienda que conecte el cristal del cable del lápiz directamente a la tierra sin pequeños condensadores? Debes revisar su hoja de datos y cualquier nota de la aplicación con cuidado.

Permítanme agregar que los diseños de Microchip MCU que he realizado tienen un chip externo I 2 C RTC. La razón de esto es que los chips RTC tienen una manera muy conveniente de conectar una batería de celda de bobina pequeña a un pin y otro pin para la conexión VDD 3V3 normal. La interfaz al RTC se realiza a través de una interfaz simple de dos cables que, en la mayoría de los casos, ya está en uso para otras cosas, por lo que no hay una carga GPIO adicional para el RTC.

Intentar soportar una batería para el MCU PIC cuando entra en modo de suspensión cuando se apaga la fuente de alimentación principal, se agregan los costos adicionales que pueden eliminarse cuando se utiliza un MCU externo. También encontré que la administración de la programación de RTC es menos susceptible a las alteraciones en el software de MCU, por lo que las lecturas actuales de RTC pueden ser más confiables.

Para su crédito, Microchip siempre ha hecho un gran trabajo al implementar los modos inactivo y inactivo de baja potencia en la mayoría de sus MCU. Sin embargo, todavía me pregunto por qué no vemos un pin VBATT separado compatible en sus partes.

    
respondido por el Michael Karas

Lea otras preguntas en las etiquetas