Je travaille sur l'un des micro-contrôleurs Freesacle. Ce microcontrôleur dispose de plusieurs sources de réinitialisation (par exemple, réinitialisation du moniteur d'horloge, réinitialisation du chien de garde et ...). Supposons qu'à cause du chien de garde, mon microcontrôleur soit réinitialisé. Comment puis-je enregistrer certaines données juste avant la réinitialisation. Je veux dire par exemple comment puis-je comprendre que où était le compteur de programme juste avant la réinitialisation du chien de garde. Avec cette méthode, je veux savoir où j'ai une erreur (en d'autres termes, un processus long) qui provoque la réinitialisation du chien de garde.
6 Réponses :
Il est écrit dans votre manuel.
Je ne connais pas ce processeur spécifique, mais dans la plupart des microprocesseurs, une réinitialisation du chien de garde est une réinitialisation logicielle, ce qui signifie que certains registres conserveront des informations sur la source de réinitialisation et parfois la raison.
Vous devez publier des informations plus spécifiques sur votre μC Freescale pour y répondre correctement.
Ceci n'est en fait le plus souvent pas écrit dans le manuel d'un MCU Freescale. Se fier au contenu de la RAM après la réinitialisation est sûr dans la plupart des cas, mais souvent complètement non documenté.
En fonction de votre microcontrôleur, vous pouvez obtenir Reset Reason, mais obtenir le compteur de programme précédent (PC / IP) après la réinitialisation n'est pas possible.
La plupart des microcontrôleurs modernes ont des dispositions pour Watchdog Interrupt au lieu de reset .
Vous pouvez configurer le périphérique de surveillance pour activer l'interruption.Dans cet ISR, vous pouvez vérifier le contexte stocké sur la pile. (Vous pouvez demander l'aide du débogueur JTAG pour vérifier la pile d'appels).
Il existe plusieurs méthodes de débogage disponibles si votre micro-contrôleur prend en charge la méthode ci-dessus.
par exemple
Dans une architecture simple basée sur while (1) , vous pouvez utiliser une minuterie HW et la redémarrer après une section de code. Dans Timer ISR, vous saurez quelle section de code consomme assez longtemps que la minuterie.
L'interruption de surveillance dans le contexte des MCU Freescale est généralement un ISR où vous vous retrouvez après réinitialisation, pas au lieu de réinitialisation. Le SP ne sera pas conservé, même si la pile elle-même l'est probablement.
Deux choses:
... amd vider et fermer le journal après chaque écriture, sinon la dernière partie peut ne pas être dans le fichier au moment de la réinitialisation.
Oui! En effet. Bon point @PaulOgilvie, il y a quelques années, alors que j'écrivais un journal sur un microcontrôleur et que je me demandais pourquoi rien n'est écrit dans la sortie, je n'arrêtais pas de penser que cette section du code n'a jamais été touchée, jusqu'à ce que je réalise la nécessité d'un < code> fflush () .
Si vous avez besoin de "vider et fermer le journal" /fflush/stdio.h sur un microcontrôleur, vous le faites terriblement mal. Ce sera juste un simple tampon en anneau résidant dans flash / eeprom.
@Lundin, je n'étais pas familier avec cette technique (ni à l'époque, ni maintenant jusqu'à il y a 9 minutes), mais cela ne tuerait-il pas flash / eeprom en peu de temps? Je veux dire, cela ne peut prendre que autant de cycles de lecture / écriture. Les appareils devaient être sur le terrain environ 30 ans. Autant que je me souvienne, nous avions une partition / log dédiée pour les logs de tous les modules (la mienne n'était pas la seule). Deuxièmement, excusez ma naïveté, mais comment l'écriture au flash éviterait-elle d'avoir à rincer? Nous n'ouvrirons pas un fichier, mais écrivons plutôt des valeurs directement dans des variables membres struct prédéfinies qui pourraient être analysées plus tard? Ou comment?
Sauf si vous avez un disque dur branché sur votre MCU (ou peut-être MRAM / FRAM), vous n'avez pas d'autre option. Oui, cela tuera flash / eeprom au fil du temps, vous devez calculer le nombre de lectures et parcourir en continu une page entière. "Flush" est un concept PC, en supposant que vous ayez une sorte de système de fichiers.
Même si vous pouviez obtenir le compteur de programme avant la réinitialisation, il ne serait pas conseillé de régler aveuglément le compteur de programme sur un autre après la réinitialisation - car il y aurait probablement eu des informations de pile et de tas ainsi que les données elles-mêmes. ont également changé.
Cela dépend de ce que vous souhaitez conserver après la réinitialisation, de certains comportements ou données? La mémoire volatile peut ou non avoir été effacée après le chien de garde (voir votre fiche technique uC) et vous pourrez détecter une réinitialisation après avoir vérifié les registres de réinitialisation (voir à nouveau votre fiche technique uC). En détectant une réinitialisation et en vérifiant la mémoire volatile, vous pourrez peut-être préparer votre uC à redémarrer d'une manière que vous préférez après l'événement improbable d'une réinitialisation. Vous pouvez créer une valeur globale et la définir sur une valeur particulière dans la portée globale, puis si elle se réinitialise, vérifiez la valeur par rapport à elle lorsqu'un événement de réinitialisation se produit - si elle est la même, vous pouvez supposer que l'autre mémoire peut également être la même . Si la mémoire volatile n'est pas une option, vous devrez consulter la fiche technique des options non volatiles, mais il est également conseillé de ne pas écrire continuellement dans la mémoire non volatile en raison des limitations d'écriture.
La plupart des MCU Freescale fonctionnent comme ceci:
Il n'y a aucun moyen de sauvegarder quoi que ce soit lors de la réinitialisation. La réinitialisation se produit et ce n'est qu'après que vous pourrez découvrir la cause de la réinitialisation.
Il est cependant possible de réserver un morceau de RAM en tant que segment spécial. Lors de la réinitialisation à la mise sous tension, vous pouvez initialiser ce segment en mettant tout à zéro. Si vous obtenez une réinitialisation du chien de garde, vous pouvez supposer que ce segment de RAM est toujours valide et intact. Donc, vous ne l'initialisez pas, mais laissez-le tel quel. Cette méthode vous permet d'enregistrer les valeurs des variables lors de la réinitialisation. Probablement - ce n'est pas bien documenté pour la plupart des familles de MCU. J'ai utilisé cette astuce au moins sur HCS08, HCS12 et MPC56.
Quant au compteur de programmes, vous n'avez pas de chance. Il est réinitialisé sans aucun moyen de le récupérer. Ce qui signifie que le seul moyen de savoir où une réinitialisation du chien de garde s'est produite est la méthode fastidieuse à l'ancienne de déplacer un point d'arrêt petit à petit dans votre code, exécutez le programme et vérifiez s'il a atteint le point d'arrêt.
Cependant, dans le cas de MCU modernes comme MPC56 ou Cortex M, il vous suffit de vérifier le tampon de trace et de voir quel code a provoqué la réinitialisation. Non seulement vous obtenez le PC, mais vous pouvez également voir le code source C. Mais vous aurez peut-être besoin d'une chaîne d'outils professionnelle sans Eclipse pour ce faire.
Freescale est maintenant NXP et l'IoT peut également être armé uC.
@P__J__ Oui, et ...? Et qu'est-ce que l'IoT a à voir avec quoi que ce soit?
Io T c'était mon dictionnaire de téléphone
La seule solution fiable consiste à utiliser un débogueur avec capacité de trace si votre puce prend en charge la trace d'instructions intégrée.
Certains appareils ont une option pour rediriger le délai de surveillance vers une interruption plutôt qu'une réinitialisation. Cela vous permettrait d'écrire le gestionnaire de temporisation du chien de garde comme un gestionnaire d'exceptions et de vider ou de stocker les informations de la pile, y compris l'adresse de retour qui indiquera l'emplacement de l'interruption.
Cependant, dans certains cas, aucune des deux solutions n'est une méthode fiable pour atteindre votre objectif. Dans un environnement multitâche ou un système avec des gestionnaires d'interruption, le code qui s'exécute lorsque le délai d'expiration du chien de garde se produit peut ne pas être le processus à l'origine du problème.
sur l'un des micro-contrôleurs Freesaclelequel? Pouvez-vous publier la fiche technique?une réinitialisation du chien de garde implique que le code ou autre est cassé, ce qui signifie que vous n'exécutez pas de code fiable qui peut marquer de manière fiable où il se trouvait avant la réinitialisation. De plus, pour ce faire, vous avez besoin de temps supplémentaire en supposant que le code fonctionne.
vous devez revenir au problème que vous essayez de résoudre et ne pas l'utiliser comme solution.
@old_timer Je crois que l'OP demande en fait comment déboguer la source d'une réinitialisation wdog.
@Lundin Je suis d'accord mais vous pouvez comprendre le problème général du débogage d'une réinitialisation de chien de garde. Comme vous l'avez bien décrit dans votre réponse. De plus, sauver le PC lui-même n'est pas la solution comme je l'ai mentionné en tant de mots. déboguer quelque chose comme ça demande de la créativité et de la chance.