¿En qué consiste realmente el restablecimiento de un microcontrolador PIC mediante MCLR?

1

Estoy trabajando en un proyecto que utiliza un microcontrolador PIC18F26K22 y se está comportando de manera extraña.

Básicamente, a veces si usted "rebota" en la línea de reinicio (tengo un botón en él, y simplemente toco el violín), se reiniciará y algunas de las interrupciones no será funcional (en este caso, la interrupción de EUSART RX).

El botón de reinicio tiene un condensador de rebote a tierra y una resistencia de extracción (10n / 10K respectivamente).

He intentado agregar un poco de limpieza preventiva a la sección de inicio de la fuente, pero no ha ayudado. En este punto, tengo un watchdog manual que detecta la falta de tráfico en serie y desencadena manualmente otro reinicio de la CPU, momento en el que todo comienza a funcionar correctamente.

Mi suposición era que todos los registros en el chip se restablecieron a su estado de "encendido" cuando se activó un reinicio (excepto quizás el registro RCON), pero el hecho de que puedo activar de manera confiable un comportamiento extraño simplemente reiniciando el chip varias veces rápidamente me hace pensar que esto no es cierto.

¿La corrupción de registros activada por el reinicio repetido es algo común (o incluso existente) con los PIC? Estoy familiarizado con los AVRs.

Editar: consideré el cambio de rebote, pero la documentación para los estados de entrada de MCLR:

  

Estos dispositivos tienen un filtro de ruido en   la ruta de restablecimiento de MCLR que detecta e ignora las pequeñas   pulsos.

Mi suposición aquí fue que los impulsos de restablecimiento más cortos que el ancho mínimo (2 uS, para esta parte) se ignorarán.

Edición adicional: De hecho, he mirado la línea MCLR con un alcance. Es libre de rebotes y satisface completamente el tiempo mínimo de espera (el período más corto que vi fue de ~ 50 milisegundos, el tiempo mínimo de espera es de 2 microsegundos). No es un rebote de MCLR.

    
pregunta Connor Wolf

4 respuestas

2

Los estados de reinicio de todos los registros están muy bien documentados en la hoja de datos. Eso le dice exactamente en qué puede confiar que se establezca de cierta manera en comparación con lo desconocido después de un reinicio. Sin embargo, en general, es una buena idea establecer explícitamente cualquier valor de registro de función especial que se base en.

Otro problema podría estar rebotando en la línea de reinicio. Mire la especificación eléctrica para el tiempo mínimo de un pulso de reinicio. Es posible que lo esté infringiendo, especialmente si considera que los interruptores mecánicos rebotan y, por lo tanto, puede producir pulsos arbitrariamente cortos durante el período de rebote.

Una forma de lidiar con esto es tener el interruptor a corto de una tapa a tierra. La línea bajará rápidamente, pero después de eso tomará un tiempo mínimo para que el interruptor se abra antes de que el voltaje de la tapa aumente al nivel máximo mínimo posible del pin de reinicio. Si hace esto, asegúrese de colocar una resistencia entre la tapa (y el interruptor y su pullup) y MCLR. Eso permite que un programador aún maneje MCLR como lo necesita. Algunos PIC requieren tiempos de subida rápidos en MCLR durante la programación, lo que impide el uso de un límite directamente en el pin.

    
respondido por el Olin Lathrop
1

El diseño de los circuitos de reinicio plantea tres problemas principales:

  1. Ingresando un estado de reinicio.

  2. Dejando un estado de restablecimiento.

  3. El manejo de los pulsos "runt" en la línea de restablecimiento que no entran completamente en un estado de restablecimiento.

Tener una línea de reinicio simplemente forzar todo de forma asíncrona en un estado conocido solucionará el problema 1. Un pulso de reinicio puede afectar algunas partes del circuito antes de que llegue a otras, pero si cada circuito se fuerza en un estado que no lo hace depende del comportamiento de otros circuitos, luego, siempre que la línea de reinicio sea lo suficientemente baja durante el tiempo suficiente, todo terminará en el estado adecuado.

Dejar el estado de reinicio plantea otra arruga, que es que si el borde del reloj pasa precisamente al mismo tiempo que se libera el reinicio, algunas partes del dispositivo pueden intentar iniciar la operación en ese ciclo mientras que otras no lo hacen. iniciar la operación hasta el siguiente ciclo. Este problema se puede resolver al tener algunos circuitos para decidir si han ocurrido al menos 3 relojes después del restablecimiento. Si llega un reloj justo cuando se está liberando la línea de reinicio, es posible que los circuitos no decidan instantáneamente si el próximo pulso de reloj es el primero o el segundo, pero debería poder decidir si el siguiente debe considerarse como el " segundo "o el" tercero ". Si ninguno de los otros circuitos que se reiniciaron hará nada hasta que la señal mencionada indique que han ocurrido al menos tres relojes, entonces todo debería comenzar a funcionar de inmediato.

Sin embargo, incluso cuando se resuelven los dos primeros problemas, el tercero permanece, y realmente no hay una forma 100% confiable de garantizar que un dispositivo no se salga con los pulsos de restablecimiento "runt" excepto en cualquiera de los dos (1) asegúrese de que no vea ninguno, o (2) requiera que la señal de reinicio esté sincronizada con el reloj, retrasando el efecto del reinicio hasta el tercer borde del reloj subsiguiente (lo que podría significar retrasarlo indefinidamente si el reloj no está funcionando) ). Hay varias formas de diseñar hardware que permitirían que un dispositivo se comporte como si los reinicios se ejecutaran de forma asíncrona, incluso si el pin de reinicio solo alimentara un solo pestillo asíncrono, pero no sé cuán ampliamente se usan esas cosas.

Según su descripción, suena como si el PIC estuviera cableando su señal de reinicio de modo que fuerza los reinicios asíncronos de los registros internos del PIC, pero no lo ha protegido completamente contra los impulsos de funcionamiento. Yo esperaría que si desea una operación confiable, la forma de hacerlo será asegurar que cada vez que la línea de restablecimiento se agote, se reduzca durante el tiempo suficiente para restablecer limpiamente todo el chip. Si el dispositivo no necesita mantener ningún estado en los reinicios, es probable que no importe si hay pulsos de ejecución en la línea de reinicio, siempre que los pulsos de ejecución reciban los válidos. Si el dispositivo no mantiene el estado, deben evitarse por completo los pulsos runt.

    
respondido por el supercat
0

Otra forma de resolver este problema y obtener una forma de onda limpia y agradable en el pin MCLR es usar un chip supervisor de reinicio. (Microchip también hace algunos de estos). Algunos de estos modelos tienen una disposición para la conexión de su botón de reinicio y continuarán reiniciando el bajo tiempo en MCLR hasta que el interruptor haya estado abierto durante una buena cantidad de tiempo. El supervisor que uso en mi placa PIC32MZ incluso tiene una conexión para un condensador, el tiempo de la extensión MCLR es un impulso de rebote en la señal del interruptor.

    
respondido por el Michael Karas
0

Una solución para la mayoría de los tipos de comportamiento espúreo es un perro guardián periódico automático. Requiere agregar al programa un pequeño código que debe realizarse periódicamente y envía un impulso para cargar un condensador que, de lo contrario, se está descargando con una constante de tiempo prolongada (por lo que el rendimiento de la velocidad general del microcontrolador apenas se ve afectado). En uso normal, nunca se permite que el capacitor se descargue más allá de un umbral que restablece el controlador. Si se produce un error imprevisto durante el uso, el regulador reinicia el controlador, que vuelve a funcionar. Los errores intermitentes se mostrarán si el perro guardián también controla un LED de advertencia, y entonces deberían ser más fáciles de diagnosticar.

    
respondido por el cuddlyable3

Lea otras preguntas en las etiquetas