¿Deben definirse siempre todas las trampas?

18

Ahora he visto dos casos con dsPIC 30F4013 donde el controlador se reiniciaba debido a una trampa indefinida. Por qué estas trampas se estaban levantando en primer lugar sigue siendo un misterio, pero esa no es mi pregunta inmediata. Estoy empezando a pensar que sería una buena práctica de programación definir siempre todas las trampas, incluso si las trampas nunca deberían ocurrir, así que recibo al menos un mensaje de error claro en lugar de un reinicio aleatorio. ¿Es esta una práctica estándar que desconozco? ¿Hay desventajas para esta práctica que debería considerar?

microcontroller interrupts reset firmware best-practice Stephen Collings
fuente
44
No es una respuesta a su pregunta, pero sufrí con ese tipo de síntomas en los sistemas dsPIC y PIC24 hace un tiempo. En mi caso, las trampas fueron el resultado de bits de código en los que hacía referencia a punteros a valores de 16 bits y estos punteros tenían valores impares (no pares), ya que apuntaban a un búfer de comunicaciones circular, y no tenía forma de saber si el valor de 16 bits comenzaría en un límite impar o par. El compilador XC16 no lo protege de los bloqueos del hardware aquí. Terminé escribiendo una macro de envoltura para estas funciones que forzó 2 depuraciones de puntero de 8 bits.
Brhans

Respuestas:

13

Mi regla informal es:

  1. Si una interrupción está habilitada, entonces debería tener un código que la maneje.
  2. Si no escribe código para una interrupción, desactívela.
  3. Si no puede desactivarlo, escriba el código para ello.

Sin embargo, incluso sin esa regla, la hoja de datos responde explícitamente a su pregunta:

Si el usuario no tiene la intención de tomar medidas correctivas en caso de una condición de error de captura, estos vectores deben cargarse con la dirección de un controlador predeterminado que simplemente contiene la instrucción RESET. Si, por otro lado, se llama a uno de los vectores que contiene una dirección no válida, se genera una trampa de error de dirección.

( Fuente , sección 8.3, primera nota)

Dado que no puede enmascarar trampas, debe manejarlas. Si no desea lidiar con la trampa de una manera particular, el método apropiado es ejecutar una RESETinstrucción.

Adam Davis
fuente
Sip. Tengo un módulo estándar con objetivos para todas las trampas.
Olin Lathrop
16

Sí, es una buena idea: el único inconveniente es un poco de tamaño de código adicional, y debe decidir qué hacer con la trampa (¿emitir un mensaje en el puerto serie? ¿Encender una luz "FALLIDA"? ¿Reiniciar en silencio? Etc. )

pjc50
fuente
44
Por lo general, solo hago que el procesador se ejecute en un bucle infinito NOP / GOTO. De esa manera, la pila no se ha corrompido con la trampa, y al depurar tengo la oportunidad de desentrañarla y descubrir qué sucedió. No consigo trampas a menudo, pero el 80% del tiempo es una trampa de dirección extraña, generalmente porque la basura se cargó como un puntero. A veces, el puntero de la pila se corrompe y produce trampas de direcciones impares. Esos son más difíciles de depurar ya que la pila ya no está allí. Afortunadamente, eso es realmente raro.
Olin Lathrop