Bonsoir.
Voici la mise à jour d'hier soir, non faite hier soir pour cause d'yeux qui se fermaient tous seuls...
J'ai commandé sur le site d'enchères mondialement connu un programmateur d'EPROM.
Mon choix s'est arrêté sur le
VP280, sans réel argument très fort pour ce modèle plutôt qu'un autre.
Google m'a trouvé la liste des composants TTL qu'il sait tester, en plus de la programmation standard d'EPROMs :
liste.
Il semble très complet dans cette liste.
Le manuel d'utilisation que j'ai téléchargé indique que l'on peut, moyennant programmation, tester des composants non connus de l'appareil.
Au passage, est-ce que quelqu'un connait un genre de "catalogue" des composants TTL 74xxx ?
Je recherche un document PDF présentant le résumé du datasheet de tous les 74xxx, à raison par exemple d'un composant par page.
Je n'ai besoin que du brochage et de la description résumée du composant (table de vérité, etc...)
Aujourd'hui, à chaque nouveau 74xxx rencontré, je dois récupèrer sa datasheet que je sauvegarde sur mon disque dur, mais j'ai rarement besoin de tous les détails.
Un résumé me suffirait.
À propos de planche à clous, j'ai déjà vu des collègues électroniciens s'en servir pour tester des cartes.
Il y a un système avec un levier monstrueux (gros comme un levier de frein à main) pour insérer/retirer les connecteurs.
Des sondes en forme de "clous" positionnées avec précision viennent effectivement mesurer un signal.
[3615 MYLIFE]
Étant môme, j'avais 2 souris (l'animal, pas le périphérique) dont une souris
albinos.
C'est vrai que les yeux de souris albinos, selon l'éclairage, fond bien penser à des LEDs rouges !
[/3615 MYLIFE]
Hier soir, j'ai suivi la méthodologie expliquée dans un message précédent.
J'ai investigué le pourquoi du comment du signal "reset".
Voici le schéma de la génération du signal reset, extrait de la page 27 :
En 1, j'ai un signal qui passe à l'état bas toutes les xxx millisecondes.
Je n'ai pas pu mesurer la périodicité du signal : il passe à l'état bas seulement quelques dizaines de nanosecondes avant de retourner à l'état haut.
C'est normal car il est issu d'une
bascule JK dont la clock est la CLOCK principale (environ 5 MHz) du PCB.
Pour voir 2 passages à l'état bas, je dois extrêment ralentir la base de temps de mon oscillo et ce dernier ne voit plus du tout le signal passer à l'état bas car c'est bien trop rapide par rapport à la base de temps.
D'après moi, la périodicité du signal reset serait soit celle du signal "/PROCEED", soit le double.
En 2, j'ai le signal "POWER_UP" à l'état haut. Il est issu d'un montage à 2 transistors + 1 porte inverseuse. Aucun problème ici.
En 3, j'ai le signal "/PROCEED". Ce signal est un signal périodique à environ 38 Hz généré exclusivement à partir de nombreuses divisions de la clock principale.
D'après moi, ce signal sert à 2 choses :
- activation temporaire du compteur mécanique de crédits
- chien de garde : vérification périodique que le signal "OPERATING" (flèche 5 sur mon extrait de schéma) est bien actif
Aucun problème ici.
En 4, j'ai le signal "/RESET" inversé ; c'est normal quand on considère que le signal "OPERATING" est à 0
En 5, le signal "OPERATING"
est en permanance à 0.
Je pense que c'est la conséquence d'une panne détectée par l'électronique du PCB.
J'observe sur le schéma que si ce signal venait à passer à 1
avant l'arrivée du front montant de /PROCEED, alors il ferait passer le signal de la flèche 4 à 0 et viendrait donc bloquer le fonctionnement de la bascule JK de gauche.
Le chien de garde serait muselé.
La porte
NOR à 3 entrées dont il est issu semble fonctionner, mais je n'ai pas encore investigué en détail là pour le moment.
L'une des 3 entrées de cette porte NOR est le signal "/COLD_START".
Ce signal est généré directement par la PROM IC138 (32 × 8 bits).
Mon oscillo montre les monstrueux glitches présents sur ce signal.
Ces glitches ne sont pas la cause directe de mon problème sur le signal de la flèche 5.
Mais ils sont bien le fruit de la PROM elle-même, car ils sont présents même quand j'isole la broche (le composant étant sur support, il me suffit de plier à peine la broche pour ne pas qu'elle soit insérée dans son contact tulipe quand je remets le composant en place).
signal "/COLD_START", broche 6 de IC138
Du coup, et c'est ce que j'ai fait hier soir, j'ai décortiqué méticuleusement les signaux autour de cette PROM.
GC339 avait indiqué à juste titre qu'un asynchronisme de commutation sur le signal du bus d'adresse pouvait être la raison de ces glitches.
En effet, supposons 2 signaux X et Y qui doivent par exemple passer de X=0,Y=0 à X=1,Y=1.
Si X change un micro-chouilla avant Y ou inversement, alors de manière très fugitive, on aura X=0,Y=1 (si Y a commuté avant X) ou bien X=1,Y=0 (si X a commuté avant Y).
Cette valeur fugitive parasite peut tout à fait expliquer un glitch de lecture : la PROM voit une demande de lecture à une certaine adresse et a le temps de trouver la donnée
avant que tous les signaux aient fini de prendre leur valeur voulue.
Les PROMs à fusible étant des composants très rapides, ce scénario est tout à fait plausible.
C'était l'objet de mes investigations de hier soir.
Mon problème est que je ne dispose d'un oscillo qui ne possède "que" 2 voies.
Il peut lire 2 signaux en même temps mais moi, je voudrais en lire 9...
Un analyseur logique TTL à 9 canaux (ou plus) coûte la peau des glaouis.
J'ai donc synchronisé le déclenchement de mon oscillo sur un signal précis : le front montant du signal "/RESET" qui me gêne tant.
Ainsi toutes mes mesures vont être synchronisée sur une référence commune ; je peux donc faire autant de mesures que je veux, il me suffit ensuite d'assembler les captures d'écran avec un
logiciel de dessin.
Voici le fruit de pas mal de boulot :
En 1
er, j'ai mis le signal /RESET, source de synchro.
Ensuite viennent les 4 bits du bus d'adresse.
Les signaux "/COLD_START", "/VECTOR" et "/PAR2" sont 3 des bits du bus de données.
Chaque trait vertical rouge correspond à un changement sur un bit du bus d'adresse.
Entre les zones
2 et
3, le trait est épais car a2 et a3 n'ont pas commutés pile-poil en même temps. C'est a3 qui a commuté un micro-chouilla avant a2. La mesure n'est pas précise, mais l'ordre de grandeur est inférieur à 16 ns (ça fait 16 milliardièmes de secondes).
D'après le dump de la PROM, voici ce que j'aurais dû trouver sur le bus de données :
| Zone | a4/a3/a2/a1/a0 | /COLD_START | /VECTOR | /PAR2 |
| 1 | 1/1/1/1/1 | 1 | 1 | 1 |
| 2 | 1/1/0/1/1 | 1 | 1 | 0 |
| 2 bis | 1/0/0/1/1 | 1 | 1 | 1 |
| 3 | 1/0/1/1/1 | 1 | 1 | 1 |
| 4 | 1/1/1/1/0 | 1 | 1 | 1 |
La zone 2 bis est la zone qui correspond au court instant où a3 a déja changé alors que a2 ne l'a pas encore fait.Observations :- pour tout ce relevé, le signal /COLD_START aurait dû être toujours lu à 1 ; hors il se mange 2 glitches
- même chose pour /VECTOR : il devrait être toujours lu à 1 sur la période de mon relevé, mais il souffre de 2 glitches lui aussi
- /PAR2 est correctement lu, mais il a aussi la maladie du glitch
- il semble que c'est une commutation sur a3 qui provoque les glitches (à confirmer par d'autres mesures)
Conclusion :De mon point de vue, je dirais que cette PROM est malade. Je ne pense pas qu'il soit normal que des bits du bus de données bagottent sur certaines transitions du bus d'adresse, alors que ces transitions n'affectent pas les valeurs à lire d'après le contenu de la PROM.
N'ayant pas un 2e PCB qui fonctionne, je ne peux pas tester les PROM accusées d'être malades sur un PCB témoin.
N'ayant pas la spécification technique détaillée de la PROM à fusible, je ne peux pas dire si son fonctionnement est en-dehors des spécifications :
- soit le constructeur indique qu'après une transition sur le bus d'adresse, tous les bits de données peuvent bagotter pour finalement se stabiliser à la valeur devant être lue ; dans ce cas le composant est conforme
- soit seuls les bits de données affectés par la transition sur le bus d'adresse doivent changer ; dans ce cas le composant est non-conforme
Finalement, je ne suis pas sûr que la PROM soit réellement malade...
J'ai vérifié que pour la génération du signal "OPERATING" (voir flèche 5 de mon 1er schéma), les glitches de /COLD_START n'ont pas d'effet sur la porte logique NOR.
À suivre : suite des investigations en marche arrière. Je vais tenter de trouver pourquoi le signal "OPERATING" reste à 0, faisant aboyer le chien de garde.
EDIT : orthographe
