Recherche de problèmes matériels avec la carte mère

Il peut y avoir de nombreux problèmes avec la carte mère, car elle est constituée de nombreuses traces sur le circuit imprimé et un défaut de manufacture ou de l'étain déposé au mauvais endroit ou mal retiré après la correction d'une erreur peut rendre la recherche de la cause du malfonctionnement très difficile à identifier. Cette section s'adresse particulièrement aux étudiants avancés, aux chargés de laboratoire ou à ceux désirant pousser leur compréhension plus loin.

Parmi les problèmes les plus courants, mais aussi parmi les plus difficiles à résoudre, il y en a deux qui ressortent: la difficulté à installer le micrologiciel sur la carte mère ou à la programmer par le port ISP (ce qui revient un peu au même) et le fait que le poste Linux ne puisse reconnaître la carte (donc, la carte n'a pas une communication par port USB fonctionnelle).

Difficulté à programmer la carte par port ISP

La nature des problèmes rencontrés varie beaucoup trop pour présenter tous les cas possibles de malfonctionnement. On donnera plutôt le résultat normal attendu et les réglages d'oscilloscope pour aider à la démarche de résolution de la personne qui cherche à identifier le problème.

Bien évidemment, une inspection visuelle de la carte mère est toujours un point de départ

En premier, prendre la carte et placer une sonde numérique sur le port B de la carte. C'est plus facile de commencer à voir ce qui se passe avec la programmation du ATmega324PA que du ATmega8. Les signaux sont plus faciles à suivre et la possibilité d'utiliser l'oscilloscope sur le port B facilite grandement la démarche. Si la programmation du ATmega324PA est réussie, la recherche du problème avec le ATmega8 pourrait être grandement réduire, voir être éliminée puisque les deux partagent des signaux de programmation communs à partir du port ISP.

Il faut savoir que la carte est programmée par quatre signaux: SCK (PB7), MISO (PB6), MOSI (PB5) et SS (reset). Ils proviennent d'un programmeur (normalement une autre carte mère fonctionnelle) connecté au port ISP. On peut le voir sur le schéma de la carte. Les trois premiers signaux se rendent assez directement aux broches du ATmega324PA, mais aussi au connecteur IDC du port B au haut de la carte. Le dernier signal SS, doit correspondre au signal de reset du ATmega324PA. Lorsque le signal SS passe au niveau bas, le microcontrôleur peut être programmé. On peut donc se servir d'une transition descendante sur ce signal pour déclencher une période d'observation sur l'oscilloscope. On peut le faire avec une sonde analogique (ici le signal en jaune au haut de l'oscilloscope – canal 1) branchée sur le reset (broche 9) du ATmega324PA. La vue de l'oscilloscope devrait donc ressembler à la figure qui suit:

Il faudra s'assurer de n'avoir qu'un seul déclenchement pour avoir un seul balayage de l'oscilloscope pour que celui-ci fige l'écran une fois le moment critique passé. Il faut donc régler l'oscilloscope en mode normal (mode coupling dans le menu triggering et réglage à normal sous l'écran avec le bouton de gauche).

Il faut aussi ajuster le déclenchement sur un front descendant sur le canal 1 analogique. Il faudra encore ici aller dans le menu triggering et compléter par des réglages en utilisant les boutons sous l'écran de l'oscilloscope. Il est aussi important de régler la base de temps à 50ms par division. De cette façon, on arrivera à avoir un résultat bien enregistré par l'oscilloscope. S'assurer aussi d'une bonne disposition des signaux à l'écran. Celle suggérée ici avec les signaux numériques regroupés au bas et le signal analogique au haut convient bien, mais peut être redisposée selon les préférences de chacun.

L'oscilloscope doit être placé en mode single dans la partie run control des réglages. Il faut aussi relier le programmeur à un poste Linux et lancer une commande de programmation ( % make fusesM324pa fait généralement l'affaire ). Normalement, si l'opération réussit, on devrait obtenir ce qui suit à l'oscilloscope:

Normalement, l'activité de programmation débute environ une vingtaine de millisecondes après la descente du signal de reset. On voit bien l'activité sur les broches D7, D6 et D5 correspondant aux signaux de programmation provenant de l'ISP. Il est peu important d'analyser plus en détail ces signaux. Ils sont nécessairement corrects s'ils apparaissent puisqu'ils proviennent indirectement d'une commande Linux déjà bien au point. Le problème commence généralement lorsqu'un ou quelques-uns, voir tous, n'apparaissent pas… Il faut alors chercher pourquoi un signal ne se rend pas. L'utilisation d'un multimètre pour tester la continuité des signaux est alors l'étape suivante dans la démarche normalement. Il faut cependant garder en tête que les observations se fond sur le port B et que les ports du ATmega324PA sont à bonne distance. Le connecteur IDC du port ISP encore plus… Il peut donc y avoir bien des endroits qui posent problème. Il faut un plan du circuit imprimer pour suivre les traces.

La mise au point de la programmation du ATmega8 est plus difficile puisqu'il est compliqué de brancher un oscilloscope pour observer les signaux. Tout de même, si la programmation du ATmega324PA est réussie, il ne devrait pas être trop compliqué d'obtenir celle du ATmega8. Au moins, les signaux arrivant aux connecteurs ISP sont bons et ils sont partagés pour la programmation des deux microcontrôleurs. Les plus souvent, le problème avec la programmation du ATmega8 vient du fait que les signaux rencontrent des résistances au bas de la carte avant de poursuivre leur course vers les broches du microcontrôleur. Généralement, le problème est justement avec la soudure de ces résistances qui coupent donc l'acheminement d'un des signaux. Vérifiez que le signal reset est bien propager à la borne de la broche 1 au ATmega8 est aussi une des premières choses à faire. Par la suite, on peut analyser les autres, SCK sur PB5 (broche 19), MISO sur PB4 (broche 18) et MOSI sur PB2 (broche 17).

Assez souvent, il est plus facile de programmer un ATmega8 sur une autre carte fonctionnelle et de le transférer sur la carte qui pose problème. Arriver à programmer le ATmega324 à partir de ATmega8 permet de reprendre les étapes de recherche de problème mentionnées précédemment et peut permettre de plus facilement trouver le problème avec le ATmega8 puisque les mêmes traces sur le circuit imprimé sont empruntées par les signaux. La seule véritable différence vient du fait dans ce cas que c'est le ATmega8 qui génère le signal de reset vers le ATmega324PA à partir des son propre signal SS (sur sa broche 16). Il pourrait s'agir d'un élément à regarder assez tôt dans la démarche également. Le signal reset étant toujours critique. Aussi, la DEL associée à l'état du ATmega8 devrait tourner au vert tout de suite. Sinon, le ATmega8 n'arrive pas à amorcer le déroulement de son programme et le problème risque d'être ailleurs (le plus souvent avec le cristal ou les condensateurs qui génèrent l'horloge ou l'alimentation – Vcc ou GND)

Difficulté à faire reconnaître à Linux la carte mère

Section à vernir…