¿Por qué los programas detienen el temporizador de vigilancia en MSP430?

Muchos programas de muestra para el MSP430 tienen su primera línea como:

WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer

¿Por qué hacen esto?

msp430

— nigromante
fuente

Respuestas:

El temporizador de vigilancia (WDT) está activado de forma predeterminada, es útil tenerlo en aplicaciones más complejas, pero hace tropezar a mucha gente nueva. A menudo no prestarán servicio al WDT en su código ni incluirán una rutina de servicio de interrupción (ISR) para manejar el evento WDT, por lo tanto, cuando su chip se reinicia se frustran mucho. Además, los programas de muestra, en su mayor parte, no intentan demostrar el WDT, por lo que está apagado.

Editar: El temporizador de vigilancia podría haber sido llamado "interruptor de hombre muerto". Su comportamiento predeterminado es restablecer el microcontrolador a menos que el firmware le informe periódicamente que todo funciona correctamente. Esto se conoce como "alimentar al perro" o "patear al perro". De esta manera, si su firmware se atasca en un bucle o deja de funcionar de la forma esperada, el watchdog no se alimenta y restablecerá el chip (con suerte a un nuevo estado de funcionamiento).

También puede usar el WDT como interrupción periódica para realizar otras tareas, lo que sea que pueda imaginar. Solo tiene que escribir el ISR relevante.

— Samuel
fuente

+1 gracias, aunque yo y otros lectores podemos buscarlo, sería bueno saber una breve explicación de por qué el WDT restablece el chip. (sin embargo, no se preocupe por agregarlo, su respuesta es lo suficientemente buena como para aceptarla tal como es (después de esperar algunas horas más para obtener otras respuestas posibles))

— nigromante

supongo que debería haber mencionado en la pregunta que soy un novato absoluto que tampoco tiene idea de cuál es el temporizador de vigilancia :)

— nigromante

@necromancer Ah, no te preocupes, he agregado la información relevante.

— Samuel

Samuel: en casi todos los casos NO debes usar un ISR para restablecer un WDT. Casi siempre es algo incorrecto. Las interrupciones pueden continuar alegremente mientras otras partes del programa están desactivadas en la-la land. Ocasionalmente es posible / necesario (con la comunicación entre el ISR y otras partes del firmware que establece efectivamente un segundo nivel de WDT), pero no se debe sugerir a un novato como primer enfoque.

— Spehro Pefhany

Además del punto de Samuel sobre las personas que accidentalmente tropezaron con el WDT, hay otra razón importante por la que debería deshabilitarse inicialmente.

Incluso si su aplicación normalmente es capaz de restablecer el temporizador correctamente, es posible que no pueda hacerlo durante el código de inicialización, por dos razones:

La inicialización puede tomar más tiempo que un simple tic de WDT, pero requiere que las interrupciones estén deshabilitadas. Esto significa que si confía, por ejemplo, en un ISR del temporizador para restablecer el temporizador, podría entrar en un bucle de arranque infinito.
No necesariamente conoce el estado del registro del temporizador en todas las MCU (es decir, el siguiente tic podría ser mucho antes de lo esperado, ya que el registro podría no comenzar en 0).

Como resultado, es una buena práctica deshabilitar el WDT como lo primero que hace, incluso si nunca lo habilitó .

Si desea usarlo, puede volver a habilitarlo inmediatamente antes de activar las interrupciones, como el último paso de su código de inicio.

— sapi
fuente

+1 gracias por agregar a la respuesta. descubrí que puedes deshabilitarlo antes de la inicialización usando la int _system_pre_init(void)función, que se ejecuta antesmain

— nigromante