Faut-il toujours définir tous les pièges?

18

J'ai vu deux cas avec dsPIC 30F4013 où le contrôleur était en train de se réinitialiser en raison d'un piège non défini. Pourquoi ces pièges ont été levés en premier lieu est toujours un mystère, mais ce n'est pas ma question immédiate. Je commence à penser que ce serait une bonne pratique de programmation de toujours définir tous les pièges, même si les pièges ne devraient jamais se produire, donc j'obtiens au moins un message d'erreur clair au lieu d'une réinitialisation aléatoire. Est-ce une pratique standard que je ne connais pas? Y a-t-il des inconvénients à cette pratique que je devrais considérer?

— Stephen Collings
source

4

Pas une réponse à votre question, mais j'ai souffert de ce genre de symptômes sur les systèmes dsPIC et PIC24 il y a quelque temps. Dans mon cas, les interruptions résultaient de bits de code où je devais faire des références aux pointeurs à des valeurs de 16 bits et ces pointeurs eux-mêmes avaient des valeurs impaires (pas même), car ils pointaient dans un tampon de communication circulaire - et je n'avais pas auparavant façon de savoir si la valeur de 16 bits commencerait sur une frontière impaire ou paire. Le compilateur XC16 ne vous protège pas des blocages du matériel ici. J'ai fini par écrire une macro wrapper pour ces fonctions qui a forcé 2 dé-références de pointeur 8 bits.

— brhans

13

Ma règle informelle est:

Si une interruption est activée, vous devez disposer d'un code qui la gère.
Si vous n'écrivez pas de code pour une interruption, désactivez-le.
Si vous ne pouvez pas le désactiver, écrivez le code correspondant.

Même sans cette règle, la fiche technique répond explicitement à votre question:

Si l'utilisateur n'a pas l'intention de prendre des mesures correctives en cas de condition d'erreur d'interruption, ces vecteurs doivent être chargés avec l'adresse d'un gestionnaire par défaut qui contient simplement l'instruction RESET. Si, d'autre part, l'un des vecteurs contenant une adresse non valide est appelé, un piège d'erreur d'adresse est généré.

( Source , section 8.3, première note)

Étant donné que vous ne pouvez pas masquer les pièges, vous devez les manipuler. Si vous ne souhaitez pas traiter le piège d'une manière particulière, la méthode appropriée consiste à exécuter une RESETinstruction.

— Adam Davis
source

Ouaip. J'ai un module standard avec des cibles pour tous les pièges.

— Olin Lathrop du

16

Oui, c'est une bonne idée - le seul inconvénient est un peu de taille de code supplémentaire, et vous devez décider quoi faire avec le piège (émettre un message sur le port série? Allumer un voyant "FAILED"? Redémarrer en silence? Etc. )

— pjc50
source

4

J'ai généralement juste le processeur exécuté dans une boucle NOP / GOTO infinie. De cette façon, la pile n'a pas été corrompue par le piège, et lors du débogage, j'ai une chance de la démêler et de comprendre ce qui s'est passé. Je ne reçois pas souvent de pièges, mais 80% du temps, c'est un piège d'adresse étrange, généralement parce que les ordures ont été chargées comme pointeur. Parfois, le pointeur de pile est corrompu et produit des interruptions d'adresses impaires. Celles-ci sont plus difficiles à déboguer car la pile n'est plus là. Heureusement, c'est vraiment rare.

— Olin Lathrop