Réparation TO7

[irios]

La même chose sur U14 broche 4.

[Daniel]

U14 broche 4 reste en permanence à l'état haut sur le TO7 en panne comme sur le TO7 en marche. C'est probablement normal, car pendant l'affichage de l'écran de présentation, il n'y a aucun accès au Basic. D'ailleurs la cartouche Basic est absente.

U14 broche 5 (/CS.RAM.SYSTEME) a une activité sur le TO7 en marche, mais n'a aucune activité (reste en permanence à l'état haut) sur le TO7 en panne.

U14 broche 14 (A12) a une activité sur le TO7 en marche, aucune activité (reste en permanence à l'état haut) sur le TO7 en panne.

En mesurant les signaux sur le bus d'adresse, j'ai observé un phénomène curieux : le plus souvent toutes les adresses sont fixes (en général toutes à zéro), mais parfois elles oscillent toutes à une fréquence élevée (8 MHz ou plus). Dans le deuxième cas, la broche 4 de U14 oscille à la même fréquence. Dans un cas comme dans l'autre il n'y a aucune modification de l'affichage.

[irios]

Vérifies enfin l'état des broches 5 et 6 du CPU (BA-BS).
En fonctionnement normal, les deux doivent être au 0 logique.

[DataPro]

A la mise sous tension rien ne s'affiche à l'écran. Première constatation : après deux minutes de (non) fonctionnement, les radiateurs du régulateur 5V et du régulateur 12V sont brûlants.

Le diagnostic est très facile : les deux condensateurs de filtrage au tantale (47µF 6V et 22µF 16V) doivent être en court-circuit. C'est la panne classique des TO7.

Merci de cette description, je pense avoir les mêmes symptomes.

[Daniel]

Il y a deux cas de figure :

1) Quand il y a une activité sur le bus d'adresses (oscillation de tous les bits), les broches 5 et 6 du CPU sont à zéro. C'est le cas le plus fréquent.

2) Quand il n'y a pas d'activité sur le bus d'adresses (je suppose que le processeur est arrêté), les broches 5 et 6 du CPU sont à l'état haut. C'est moins fréquent, pas facilement reproductible, mais je l'ai observé plusieurs fois.

Quand il y a une activité sur le bus d'adresse c'est une oscillation, pas un programme qui s'exécute. Je relève sur chaque bit une fréquence fixe. Approximativement :
A0 = 500 kHz
A1 = 250 kHz
A2 = 125 kHz
A3 = 62 kHz
A4 = 31 kHz
A5 = 16 kHz
A6 = 8 kHz
A7 = 4 kHz
A8 = 2 kHz
A9 = 1 kHz
A10 = 488 Hz
A11 = 244 Hz
A12 = 122 Hz
A13 = 61 Hz
A14 = 30 Hz
A15 = 15 Hz

[__sam__]

C'est un compteur qui tourne à 1Mhz sur le bus d'adresse. Ca ressemble fichtrement au HCF ce truc!

[Totor le Butor]

Manifestement il va chercher quelque chose sur une adresse haute ce qui est la procédure d'init classique pour un micro mais ça à l'air de coincer juste après....
Concentre toi plutôt sur les nivaux de tensions présent sur les sorties des différents boitiers, tu trouveras peut-être une patte ayant un niveau batard dans le 2 à 3 V max ou un niveau fixe beaucoup trop près du 0 ou du 5v, signe d'une sortie de circuit abimée.
L'image du défaut à l'écran ressemble beaucoup a ce qu'on trouve habituellement quand une ram est HS.

Fait attention à la tentation de comparer 2 machines identiques dont une est en panne, ça parait plus simple mais tu as une machine HS qui s'arrête relativement tôt dans sa procédure d'init alors que l'autre va jusqu'au bout. Les signaux présents sur l'une ou l'autre machine ne sont pas comparables.
Personnellement je trouve que c'est une technique qui permet de lever des doutes et de mieux comprendre le fonctionnement mais qui souvent amène des erreurs de diagnostique et fait changer des pavés inutilement, en bref j'aime pas

[Fool-DupleX]

C'est un compteur qui tourne à 1Mhz sur le bus d'adresse. Ca ressemble fichtrement au HCF ce truc!

Oui ... mais qu'est-ce qui pourrait mettre le 6809 en HCF ? outre l'opcode, y'a-t-il une combinaison d'I/O susceptible d'enclencher le HCF ? Il se pourrait qu'il y ait une soudure seche sur les datas du socle de la rom et qu'un octet d'instruction normal se transforme en hcf a cause d'une mauvaise lecture.

[__sam__]

Oui ... mais qu'est-ce qui pourrait mettre le 6809 en HCF ? outre l'opcode, y'a-t-il une combinaison d'I/O susceptible d'enclencher le HCF ?

je ne saurais dire. Mais en fait il n'est pas besoin de l'instruction HCF pour avoir la présence d'un compteur à la fréquence de 1Mhz sur le bus d'adresse. Il suffit que le bus de donnée présente en permanence le prefix d'opcode de page 2 ou 3 ($10 ou $11) auquel cas le 6809 va chercher l'octet suivant au prochain cycle. Comme cet octet sera encore un $10 alors il repartira pour un tour et on observera le défilement des adresses successives à 1Mhz sur le bus d'adresse.

Un $CE coincé sur le bus de donnée va faire un LDU #$CECE (3 cycles) et va donc produire lui aussi un compteur régulier à 1Mhz sur le bus d'adresse. A noter que bien que $1A (ORCC #$1A) prend aussi 3 cycles, on aura pas un compteur régulier: on va voir les adresses croissantes pour les 2 premiers cycles (fetch opcode + donnée) mais le 3eme cycle (exécution) ne fera pas d'accès à la mémoire.

Cela dit, ici on a A0 qui tourne à 500khz, ce qui semble exclure le HCF ou les $10, $11 ou $CE qui produisent du 1Mhz.

Cependant si on a un $12 collé sur le bus de donnée on aura une série de NOP engendrant un compteur à 1/2 Mhz sur le bus d'adresse (car nop = 2 cycles). Cela correspond assez à la fréquence qu’observe Daniel. En outre $12 est interressant car il a peu de bits à 1 et beaucoup à 0. Un court-circuit a peut-être plus de chance de le produire qu'un $AA ou $55.

Daniel, est-ce que tu as eu la curiosité de voir ce qui circule sur le bus de donnée ?

[Fool-DupleX]

Deux-trois remarques annexes :

- il n'est pas exact que le basic n'est pas accede pendant le boot, car le moniteur va aller lire le titre de la cartouche pour l'afficher dans le menu (mais vu l'image a l'ecran, on n'en est pas encore la)
- un defaut de puce de ram a mon avis ne donnerait pas cette image fixe
- lorsque le cpu est en halt (par exemple quand la ligne reset est tiree), le bus d'adresse est en haute impédance et c'est $FFFF qui devrait être lu, pas $0000.

[__sam__]

- lorsque le cpu est en halt (par exemple quand la ligne reset est tiree), le bus d'adresse est en haute impédance et c'est $FFFF qui devrait être lu, pas $0000.

Oui et en plus (BA,BS) à (0, 0) signifie que le CPU est parfaitement "Running": il est supposé "fetcher" des instructions.
http://www.maddes.net/m6809pm/sections.htm#sec1_11_8

[Daniel]

Daniel, est-ce que tu as eu la curiosité de voir ce qui circule sur le bus de donnée ?

Tu me connais un peu, je suis curieux de nature, alors, évidemment, j'ai scruté le bus de données à l'oscilloscope. Le scoop est qu'il s'y passe des choses : les données changent de façon cyclique. Malheureusement, avec un oscilloscope de collection très vieux et très fatigué, difficile d'en dire plus. Sauf que tous les bits ne changent pas à la même fréquence, et deux ou trois sont fixes.

L'hypothèse du processeur exécutant en boucle des instructions à 2 cycles est plausible. Le problème est que ces instructions ne sont pas les bonnes. Il y a certainement un problème d'accès à la mémoire (ROM ou RAM).

[irios]

Vous partez tous dans une mauvaise direction car l'eprom n'est même pas sélectionnée et c'est elle qui va donner les instructions donc moi je dirais que le démultiplexeur 139 ne fait pas son boulot. Daniel a bien constaté qu'il n'y avait pas d'activité sur le signal de sélection de l'eprom. Change le 139 si tu le peux et refait tes tests.

Fait attention à la tentation de comparer 2 machines identiques dont une est en panne, ça parait plus simple mais tu as une machine HS qui s'arrête relativement tôt dans sa procédure d'init alors que l'autre va jusqu'au bout. Les signaux présents sur l'une ou l'autre machine ne sont pas comparables....

Là je ne suis pas d'accord avec toi car sur une machine qui fonctionne, quelque soit la phase, init, démarrage, en fonctionnement, cela permet de connaitre où cela pêche, le principe de dépannage par dichotomie comparative !! A chacun ses méthodes hein !!

[gilles]

cela n'élimine pas forcément l'hypothèse de sam sur l'état du système lors du relevé (sans que cela donne la cause de la panne).

Le proc lit (une seule fois ou au moins très rapidement dans sa séquence de boot) l'instruction HCF et le système reste dans cet état. il ne tentera plus de sélectionner l'eprom par suite.
Les fréquences relevées correspondent bien à un compteur à 1 MHz, la transition sur le bit A0 se fera pour une valeur sur 2, ce qui revient à une fréquence de 500KHz.

[irios]

J'ai bien regardé la documentation technique du 6809 et le schéma du TO7, il n'y a pas 36 solutions :
1- Soit le reset ne ce fait pas correctement --> Voir les réseaux RC, diodes et surtout les condensateurs
2- Soit le halt est actif sur le processeur --> Voir l'état sur la broche qui va bien, soudure séche
3- Soit le dma est actif --> Voir soudure séche
4- Soit il n'accède pas aux DATA
--> Voir si les amplificateurs de bus d'adresses fonctionnent correctement : un bit, voir plusieurs HS
--> Voir si les amplificateurs de bus de données fonctionnent correctement : un bit, voir plusieurs HS
--> Voir si le démultiplexeur d'adressages fonctionnent correctement : à priori ce n'est pas le cas, voir bits d'adresses A12, A13, A14 et A15 ce qui revient à vérifier les amplificateurs de bus d'adresses U13

* Les amplificateurs ont déjà été changés donc OK.