[wip] réparation MV1FZ #8

Hello,

Petite réparation du soir : symptôme, Watchdog...
Je regarde ce qui sort du bios, A14 n'est plus relié au cpu.
Je patch et j'installe un diagbios.
La carte démarre mais.....
J'ai l'écran du diagbios qui s'affiche et affiche : Watchdog delay, the system is stuck in Watchdog et la carte redémarre .. j'ai ce message environ 2 fois par seconde.

Les continuités avec sp1, 64k et wram sont ok.

Quand je regarde les wram :
L'une est en WE High tout le temps et l'autre à son WE qui bagotte entre haut et un état indéterminé très rapidement.

Bizarre que le Watchdog s'enclenche. Serais-ce un problème de wram ?

Quand je désactive le Watchdog, je peux observer que le 68k est parfois halt, parfois, non.
Quand il ne l'est pas, l'écran du diag est bloqué sur testing crc bios. Le bus de donnée est actif mais pas sur tous les bits.

Est-ce que ce sont des tests avec la version actualisée du Neo Fiag?

Yes !!

Exploration supplémentaire : quand le cpu n'est pas encore planté, je regarde l'état du bus de donnée. Certains bits font du haut/bas alors que certain sont bloqués haut.

J'ai désactivé le vcc des rams (est ce que ça fait pareil que de les dessouder ? Naïvement ..) de poids faible pour comprendre si ce avait un effet sur le second bit de donnée qui est haut.... aucun effet. 

De nombreux bits sont dans un état constant haut ou bas ce qui laisse supposer (ai je raison ?)que quelque chose pollue le bus de donnée. A part les wram, qui d'autres est connecté sur ce bus ? Il y a à la fois des bits de poids faible et de poids forts qui sont fixes ce qui exclue certain chip je pense.

Finalement j'ai retiré les wram et les bras pour voir, j'ai tjs sporadiquement ce message et les mêmes état sur les bit de donnée. C'est donc autre chose qui perturbe le cpu...

C'est là qu'avec une seule sonde, il est difficile de savoir quelle puce est activée (ligne /OE) au moment où ton signal devient bizarre. La connexion marche globalement plutôt bien pour que tu arrives à afficher du texte à l'écran er a lancer le CRC.
Il est possible aussi que le calcul de CRC de la ROM utilise la RAM. Ce serait couillon mais c'est déjâ un miracle d'avoir réussi à cider tout ça sans variables ou appels de fonctions!
Tu as jeté un oeil aux plans sur le site du wiki, pour voir ce qui etait raccordé au bus?

Yes, j'ai tout épluché, j'ai désactivé le Watchdog. Quand le cpu n'halt pas (une fois sur 3 on va dire), il y a bcp de bit de data dans un état haut (reparti sur poids faible et fort) et certains autres qui font du haut/bas.
J'ai un analyseur logique 8 voies. Je dois le sortir du carton Tu me conseillerais le regarder quoi comme signaux ? Les OE des chips sur le bus data et le halt du cpu ?

J'arrive sur l'écran crc avec le Watchdog désactivé sinon le système reboot sans que j'ai le temps de voir le message. Les tests wram sont après le crc. Avant, il y a juste la vérif du bus d'adresse du bios.

Avec ton analyseur, tu peux regarder tes lignes de données douteuse (une à la fois, pas la peine de brancher tous les fils!) et sonder avec un autre brin les broches d'activation des différentes puces (dont l'EPROM) pour voir si ça correspond:
- à une puce qui ne sait pas parler
- à plusieurs puces qui ne peuvent pas parler parce qu'une autre refuse de se taire
Bizarre que ça reste figé pendant le calcul du CRC!

J'ai bloqué le Watchdog donc on dirait que le cpu essaye de calculer le crc ( le bus de donnée parle) et au bout d'un moment, il halt. Ça se trouve c'est le 68k qui est HS ?
Je te dis ça dans quelques jours !

Si je comprends bien aucune puce ne devrait parler en même temps, c'est bien ça ? ( OE active )

Sur le bus de données, c'est une puce à la fois. Sinon, c'est court-circuits assurés. On appelle ça un conflit de bus (les adresses c'est pareil, mais tu n'as que le 68000 et la puce Yamaha qui savent écrire dessus, a priori).
La ligne HALT n'est pas forcément à l'initiative du 68000. C'est une ligne à collecteur ouvert (contrairement aux lignes d'adresses), avec un pullup. Plusieurs puces peuvent écrire dessus.
Il y a potentiellement une ligne BUS_ERROR ou un truc comme ça sur le 68000, qui passe à 0V en même temps que le HALT si c'est le CPU qui se coupe volontairement? Je ne suis sûr de rien, je n'ai pas trop creusé ça.

Effectivement j'ai vu le pin buserr passer bas parfois. Le buserr c'est sur le bus de données ? Ou d'adresse ?

Jz ne saurais le dire. Il faut faire un Ctrl+F dans la doc du 68000 .

Je me fie à la définition de chatgpt, c'est le data bus :

The "bus error" or "buserr" signal in the context of the Motorola 68000 processor is a hardware-level exception or interrupt that occurs when there is an error on the data bus during memory access or data transfer operations. This signal is generated when the processor detects issues like invalid memory addresses, unaligned data accesses, or other bus-related problems.

When a bus error occurs, the processor enters an exception handling routine, typically invoking a specific exception vector. Software can then respond to this exception, for example, by handling the error gracefully or by terminating the program.

In summary, the "buserr" signal on a 68000 processor is a hardware interrupt that indicates a problem with data access on the memory bus, and it allows for error handling within the software.

OK, donc ça ne provoque pas un /HALT du processeur. Quelqu'un d'autre est en cause. Ce n'est pas le Neo-B1 qui produit ce signal?

A priori, si ça peut provoquer un halt

Ah? Si l'interruption n'est pas masquée? Dans ce que tu écris au-dessus, en tout cas, il est indiqué qu'elle est gérable par soft...?
Ca tourne combien de temps avant de se figer? Ca ne va oas faciliter tes observations!
Tu as la dernière version du logiciel de Saleae Logic? Ca se rapproche d'un oscillo avec de la lecture en boucle, c'est super agréable de bosser avec.

Je vais tester ça ce WE
Le temps de plantage est variable de immédiat à plusieurs minutes

Bonsoir,
En désactivant le WD, j'ai branché la sonde logique : a peine le slot démarré, je vois le halt qui néo B1 qui s'affole entre haut et bas, reçus par le 68k. Peu de temps après, le bios s'active (CE) et la data sort sur le bus. Au bout d'un moment, tout s'arrête - le halt reste haut (sur le message du CRC) et ne reste juste le CE du bios qui oscille.

Est ce un comportement normal du neo B1 ??? Je serai bien d'avis d isoler le pin halt du B1 vers le 68k....

Le cycle de démarrage passe par le Neo-B1. Il se synchronise avec le LSPC2-A2. L'un des deux utilise des sous-horloges, et il faut qu'elles démarrent toutes en même temps.
Cela dit, j'aurais dut que ça passait par la ligne de reset et pas par la ligne halt.
Quoi qu'il en soit, le Neo-B1 bloque oe CPU au démarrage. D'ailleurs, du coup, en cas de panne du LSPC, le CPU ne démarre pas.
Si la ligne /OE de la ROM s'active, c'est que le CPU y accède. Il est censé calculer son CRC, donc les accès à la ROM doivent alterner entre la lecture des instructions qui calculent le CRC et le contenu global de la ROM.
La RAM n'est pas sollicitée pendant le calcul? Si tout ce fait sans appels de routines et sans variables, c'est possible.

Ah, donc tout ces battement sont peut être normaux. Le crc n'a pas besoin de ram, j'ai virer les 4 rams Work et backup et ça ne change rien. Il m'est arrivé de rares fois à l'allumage d'arriver jusqu'au message "work ram error" et c'est l'étape d'après le crc. J'en conclus que je dois mettre les sondes de l'analyseur logique sur autre chose de complémentaire pour faire la correlation plus poussée. Bizarrement, sur certains démarrages, j'ai directement le click of death et là, je ne vois pas les oscillations du signal de halt...
Je tacherai de faire une chronologie plus détaillée.

Les petites avancées du jour : j'ai mis mon analyseur logique sur la carte et je vois que le halt s'enclenche en même temps que celui du neo-b1.
Je lève le pin halt du neo-b1 et il reste celle du 68k qui s'active. Il semblerait que le halt vienne du 68k lui même ? Qui d'autre peut générer un halt ?

J'ai câbler les autres pièces et je ne vois rien d'anormal à part qu'en pleine lecture du bios, le 68k halt puis reset. Pas trouvé d'autre déclencheur.

J'ai par contre remarqué que l'écran sur lequel il reset est aléatoire : des fois le calcul du crc reste bloqué, des fois il passe mais avec une erreur, des fois j'ai carrément le bios qui plante avec une erreur invalide. C'est comme en fait, le 68k exécutait n'importe quoi aléatoirement... (Cf photo)


N'est pas tout simplement le 68k qui est HS ?!

Il n'y a pas une broche BUSERR ou un truc du genre sur le 68000? (Désolé si j'en ai déjà parlé, je raccroche les wagons). Possible que quelqu'un parle sur le bus alors qu'il n'a pas été invité. D'où les conflits aléatoires. Une piste de broche /OE ou /CE flottante quelque part, par exemple, ou carrement une RAM qui reste bloquée en lecture...

J'ai ressorti slot !
J'ai levé tous les pins data du E0 et du C1 pour être sûr d'avoir aucune perturbation. J'ai changé le hc259 aussi.
Il n'y a pas de bus erreur qui reste toujours haut. J'ai levé le pin halt du B1 et ça ne change rien -> le halt vient du cpu dans ce cas ?

Le CPU a le droit aussi, en effet. C'est une ligne flottante avec un pullup. Tout le monde peut tirer dessus.
Je ne pense pas que les wait cycles soient gérés avec ça, mais probablement les conflits de bus.
Ma broche /BERR est bien à l'état haut?
Tu peux aussi avoir un CPU HS, ou peut-être simplement son pullup interne. Tente éventuellement de coller une résistance de 10k entre la ligne /HALT et le +5V?