Woof Woof : Chien de garde matériel

[GeekElec]

Bonjour à tous,

Je suis nouveau parmi vous. Après avoir passé de nombreux moments à me renseigner sur divers projets et domaine grâce à ce forum, je bloque sur la mise en oeuvre d'un watchdog matériel permettant de réinitialiser la VMC (Machine) et non seulement le µP (DSpic33) suite à un plantage dans la communication I2C. La machine contient un monnayeur et si l'alimentation générale de la machine n'est pas réinitialisé, certains modules utilisant le bus I2C restent planté mais le monnayeur, en contre-partie, continue d'accepter des pièces.. Pour cela je recherche comment mettre en place un wdt externe fiable et performant, pouvez-vous m'aider?
Merci d'avance à ceux qui prendront le temps de lire ce message.
-----

[jiherve]

Bonjour et bienvenue,
voir chez MAXIM (pas le restaurant ).
De mémoire donc assez ancien MAX690
Mais cela ne résoudra pas tout il faudra sans doute induire une coupure alim pour que tout reparte du bon pied.
Mais avec une routine correcte le µC pourrait aussi le faire : distinction reset Watch Dog des autres sources de reset, ne surtout pas utiliser l'astuce constant à écrire une valeur en mémoire pour faire ce distingo.
JR

[azad]

Sûr, que si le monnayeur reste actif, cela pose de gros problèmes.
Mais les lecteurs de billets de banque ou de pièces de monnaies possèdent tous une entrée d' inhibition (une par canal parfois ou une générale).
Il serait bien surprenant que l'état "planté" du système n'active pas une sortie permettant d'une part d'invalider les lecteurs de monnaie et peut-être de tout redémarrer (y compris l'alimentation). Je connais par exemple un validator (lecteur de billets) qui envoie une alerte si le bus auquel il est relié devient muet. Rien que cela suffit à résoudre tout problème.

Un bon site pour obtenir des renseignements et outils de programmation : ICI

[MiKL.66]

Bonjour,

permettant de réinitialiser la VMC (Machine) et non seulement le µP (DSpic33) suite à un plantage dans la communication I2C

Le plantage arrive au niveau de l'I2C du dsPIC ou au niveau d'un des périphériques ?

Car je ne vois pas comment un WatchDog peut détecter le plantage du bus ?

Utilises tu le flag qui indique que le bus à planté ?
Je ne connais pas le registre pour le dsPIC, il suffit de regarder dans le datasheet ... (je peux chercher si tu ne trouves pas)
Il suffit de réinitialiser le bus I2C et ça repart.

Mickael

[A voir en vidéo sur Futura]

[GeekElec]

Merci pour vos réponses.

J'ai pu lire un peu la Datasheet du MAX690 néanmoins je n'ai pas compris grand chose à son utilisation..
Le plantage se fait au niveau d'un périphérique (carte Bouton/Led). Je ne sais pas quel flag permet de détecter une erreur sur la communication I2C, je veux bien de votre aide (slurp).
http://ww1.microchip.com/downloads/e...Doc/70594B.pdf => DSpic33FJ256MC710A
De plus j'ai du mal à concevoir comment je pourrais faire une coupure de l'alimentation générale en cas de plantage et le réactiver de manière autonome.

[MiKL.66]

Bonjour,

Le plantage se fait au niveau d'un périphérique (carte Bouton/Led). Je ne sais pas quel flag permet de détecter une erreur sur la communication I2C, je veux bien de votre aide

Tu as le même genre de problème que moi.
Moi j'ai ce problème avec un MCP23008 qui, 1 fois de temps en temps me génère un plantage (que je n'ai pas encore résolu).
Mon PIC24 étant en master plante !

Voilà ce que je fais (cela se trouve à la page 207) :
if (I2C1STATbits.IWCOL) // Write Collision Detect bit (utiliser "I2C2STATbits.IWCOL" pour le bus N°2)
init_i2c1 (); // J'initialise le module I2C

C'est peut être pas la meilleure technique, mais ça me dépanne bien pour le moment, le temps de trouver la solution du plantage (car il y a surement une raison ... lol).

[GeekElec]

Merci Mikl pour ta réponse. Oui le problème semble être très proche du mien, néanmoins j'utilise un MCP23017.
Je vais essayer de générer le plantage et tester si en réinitialisant l'I2C le problème disparaît, néanmoins il me semble bien que lorsque je reprogramme le DSPic (réinitialisation de tout..) le périphérique reste planté.
C'est pour cela que je recherchais un moyen pour faire une coupure de l'alimentation générale. En regardant l'utilisation d'un NE555, je ne comprend pas comment cela pourrait mettre en oeuvre un watchdog externe (pour l'alimentation).

[MiKL.66]

Si tu n'as pas une broche de reset sur ton périphérique, c'est pas évident !

Je ne sais pas comment tu utilises ton périphérique ... mais si tu communiques régulièrement, tu peux utiliser un timer !
A chaque fois que tu auras communiqué avec ton périphérique, tu remets le timer à zéro.
S'il y a un problème, il y aura débordement du timer et tu pourras faire une action de reset en coupant l'alimentation de tes périphériques !

à suivre ...

[luc_1049]

Bonjour

Un maxim peut générer un reset si l'alimentation baisse ou si un signal est devenu fixe au bout d'une période fixée en dure dans le maxim. ce signal est normalement commuté de l'état 0 à 1 régulièrement par un port du micro.
C'est donc au logiciel de vérifier de faire commuter ce signal, par exemple dans une tâche temps réel.
Dans l'état pour une communication i2c qui est sans doute dans la même tâche c'est à vous de la découper en petits morceaux via un automate codé en vous assurant que chaque état n'est pas trop long et qu'entre chaque état vous faite commuter le chien de garde.
Vous pouvez aussi considérer la communication dans sa totalité si elle n'est pas trop longue et commuter le chien de garde avant et après.
Ceci dit faire déclencher le chien de garde avec tout ce que cela implique reboot du logiciel ne me semble pas être la bonne solution. Il vous faut contrôler ce périphérique i2c par exemple en mettnt un hors temps ou "timeout" dans le logiciel lorsque vous attendez une réponse. Ensuite effectivement si vous n'avez pas de réponse faire une réinitialisation de la communication ou plus radicale du périphérique ou du système i2c à chaud logiciel ou matériel. Une solution étant donc de séparer l'alimentation de ce circuit du micro si c'est la seule solution de le réinitialiser.
Regardez quand même déja si vous gérez bien la communication, laissez vous le temps au périphérique de répondre ?
Coté matériel vérifiez que les règles de base, découplage, qualité de l'alimention qui ne s'écroule pas, chronogrammes sont parfaitement respectés en tenant compte des dispersions dans les chronogrammes, transition correcte pas de signaux trop arrondi.
Vérifiez notamment que le circuit ne reçoit pas de transition en raison de polarisation non définie, signaux flottant.

cdlt