ESH-3: Réparation - partie 1

Le récepteur de mesure ESH3 couvre une gamme allant de 9kHz à 30MHz. Conçu dans les années 80, il est piloté par micro-processeur. Son dépannage n'est pas une sinécure et suppose de disposer de l'outillage ad'hoc et de la documentation associée.

Photo extraite de la présentation commerciale d'époque

Le système de commande de ce récepteur est ainsi constitué de deux cartes:

- la première carte assure l'affichage et l'entrée des informations. Elle embarque un contrôleur 8049 dédié à la gestion du clavier et un micro-contrôleur 8048 responsable de la gestion des affichages;

 - la seconde carte pilote l'ensemble du récepteur à partir d'un processeur 8085 et de périphériques spécialisés dont un 8090 pour la gestion du bus GPIB, un 8155 fournissant des entrées/sorties mais aussi 256 octets de RAM utilisés pour la pile (stack) du processeur. Les autres entrées/sorties sont gérées par un grand nombre de lach 74LS373.

Ces cartes ont été conçues pour pouvoir être dépannées en s'appuyant des routines spécifiques nécessitant l'utilisation d'un analyseur de signature HP5004A, certaines informations utiles pouvant aussi être présentées sur les afficheurs. Il conviendra de disposer de la liste des signatures attendues pour la version installée du firmware.

Le premier test à engager est celui permettant de valider le bon fonctionnement de la carte d'affichage. Le déplacement du strap BR4 situé à coté du 8048 active une routine de test. Toutes les diodes LED doivent s'allumer ainsi que les grands afficheurs alpha-numériques, les autres afficheurs étant pilotés par la carte principale. Les signatures peuvent être relevées et comparées à celles présentes dans une table hélas non fournie dans le manuel de service dont je dispose.

Le second test visera à vérifier le bon fonctionnement de la carte principale, celle-ci devant être raccordée à la carte d'affichage. Le déplacement du strap BR1 devrait normalement conduire à l'affichage du message 'SIG-ANALYSIS' sur l'afficheur principal, à l'affichage d'un compteur sur les petits afficheurs alphanumériques et à une valeur numérique fixe sur l'afficheur des fréquences. Si tel n'est pas le cas, les signatures des principaux périphériques pourront être relevées, une table étant fournie dans le manuel de service pour la version 1.4 du firmware mais utilisable au moins pour la version 2.0. On pourra aussi pister la panne en passant le processeur en mode 'Free Running' par le déplacement des straps BR2 et BR5 puis en testant les signatures du bus d'adresse sur tous les composants utilisant ces signaux, ces signatures étant par définition indépendantes du logiciel embarqué. On en profitera pour vérifier les rampes générées par les convertisseurs DAC.

Le procédé d'analyse en mode 'Free Running' est ici un grand classique: le bus de données est déconnecté coté périphérique et le code de l'instruction 'NOP' (00 pour le 8085) est présentée sur le bus de données coté processeur. L'exécution de cette instruction conduira à incrémenter le compteur d'adresse instruction après instruction et ainsi à parcourir tout l'espace d'adressage. On pourra ensuite vérifier les 8 signatures du firmware contenu dans les EPROM en relevant celles-ci sur les 8 signaux du bus de données, du coté périphérique. Attention, la liste de ces signatures est directement dépendante du contenu des EPROMs et donc de la version du firmware.

Dans notre cas, un affichage aléatoire se produit lors de la mise sous tension. Il faut dire que la carte principale est en bien mauvais état, certaines pistes proches de la batterie sont corrodées - la batterie est immédiatement enlevée, d'autres pistes et broches de composants exhibent une oxydation probablement liée à l'environnement d'utilisation du matériel (trés certainement salin), à son stockage et aux effluves liées à la fuite de l'electrolyte de la batterie. Les composants sont tous enlevés, et plongés avec la carte dans plusieurs bains successifs d'eau distillée pour être savonnés et nettoyés avec bonne brosse.

L'ensemble est ensuite mis à sécher au soleil de juillet. Rien ne permet de dire si l'oxydation ne reviendra pas avec le temps...

Les deux cartes sont remises sur l'établi, interconnectées entres-elle puis alimentées: le défaut précédent est toujours présent, le test des afficheurs et le test du bus d'adresse en mode Free Running sont tous deux corrects mais les tests des signatures en mode d'analyse ne passent même pas. Ce problème apparaît rapidement être lié à l'absence du signal de commande de l'analyseur. La décision est rapidement prise de procéder par petits pas en analysant tout d'abord le firmware pour comprendre la logique des tests et éventuellement en déduire une piste pour déterminer l'origine de la panne.

Le désassemblage du firmware ne pose aucun problème pas plus que la recherche et l'analyse du code dédié aux tests. Je dispose ainsi de la succession des codes d'instruction déroulés lors du passage en test et des addresses associés. Le démarrage de cette séquence peut alors être étudiée directement sur le bus du 8085 à l'aide de mon bon vieil analyseur logique Tek 1241 programmé pour démultiplexer le bus du 8085 et présenter ainsi une colonne contenant l'adresse et une autre la donnée. Une programmation qui s'avère plus compliquée qu'initialement envisagée.

En final le résultat est là, et je n'ai pas besoin d'utiliser le ROM Pack dédié au 8085 pour déterminer l'origine du problème: l'un des bits de données en provenance des périphériques est incorrectement retranscrit du coté processeur par le tampon 74LS245. Celui-est remplacé, et la séquence de code se déroule presque comme prévue hors la présence de deux instructions d'écriture en mémoire haute (90FF/90FE). Il me faudra cependant un certain temps pour comprendre qu'il s'agit de la sauvegarde du pointeur dans la pile (RAM du 8155) avant l'appel à la fonction de test! Les signatures s'avèrent cependant toujours invalides, que la carte d'affichage soit raccordée ou non. Soupçonnant que les RAM statiques de la carte puissent être non fonctionnelles au regard de l'age, j'avais commandé par avance quatre PDC5101. Une bonne initiative car le remplacement des RAMs conduit à l'affichage tant attendu de la séquence 'SIG-ANALYSIS' sur l'afficheur principal et à l'affichage du modèle suivi de la version hors mode analyse.

Une nouvelle vérification des signatures met en évidence deux valeurs incorrects, l'une en sortie d'un démultiplexeur 74LS138, l'autre en entrée du 8155. Le remplacement de l'un et l'autre ne change rien, nous en déduirons qu'il s'agit d'une erreur dans les tables fournies dans le manuel. Une remarque à propos du changement des différents composants: la corrosion partielle de certaines pistes et l'oxydation des soudures et pattes de composants impose une approche stricte pour le remplacement si l'on veut limiter les dégâts. Les pattes du composant à changer sont toutes coupées à ras de celui-ci. Ces pattes sont ensuite extraites une à une à l'aide d'une brucelle et du fer à souder. La soudure restante est éliminée au fer à dessouder et les pistes inspectées à la loupe. Inéluctablement, quelques pistes apparaîtront coupées au ras du trou métallisé. Une réparation peut alors être faite à l'aide d'un bout de fil à wrapper soudé sur la piste et engagé dans le trou métallisé. 

L'ensemble du système de commande semblant fonctionnel bien que non encore raccordé au reste du récepteur, un dernier contrôle est effectué sur le mécanisme de régulation du courant consommé par la carte d'affichage, le transistor de régulation devenant brulant au bout de quelques minutes. L'idée est ici d'absorber les différences de consommation de la carte d'affichage dues au multiplexage de certains afficheurs et au changement d'état d'autres indicateurs afin de limiter le bruit transmis à la secteur analogique du récepteur. Une régulation de type Shunt est mise en oeuvre s'appuyant sur un transistor piloté par la mesure de la consommation par la différence de tension développée au borne d'une résistance. Le schéma étant bien peu clair, j'ai retranscrit celui différemment pour faire mieux apparaitre les deux boucles de régulation.

Les composants entrant dans cette régulation ont été testés corrects me laissant perplexe jusqu'à ce que je comprenne l'origine du problème: d'autres composants sont normalement alimentés à partir de la carte d'affichage laquelle n'est actuellement pas connectée au reste du récepteur. La régulation joue alors son rôle en compensant la consommation de ces derniers.

La réintégration des cartes de commande dans le récepteur résout en effet ce problème mais en fait apparaître hélas un autre: le rail d'alimentation -10V tombe dès le démarrage. Le rail ne semble pas être en court-circuit, et aucune carte n'apparaît être réellement à l'origine du problème. Il va donc falloir investiguer du coté de la régulation de ce rail et de la protection en intensité.

Comment ai-je pu imaginer que seules les cartes de contrôle puissent être en panne !

Nota: je recherche à ce propos le schéma de la carte d'alimentation analogique 335.9613 qui diffère notablement de la version 354.9815 intégrée à mon manuel de service.

Nota: I'm looking for the schematics of the analog power supply card  335.9613 which is not the same as the 354.9815 version which is included in my service manual.