Wenn sich das Problem mit einem Firmware-Update lösen ließe, wäre das natürlich ideal.
Prinzipiell geht das zwar, aber da sind dicke Bretter zu bohren:
Wären die JTAG-Anschlüsse des CPLDs verfügbar geblieben, könnte man das Problem bequem in der Schaltung debuggen. Hier leider nicht: mangels verfügbarer Anschlüsse wurden aber in der FE3 die JTAG-Anschlüsse zu normalen Ein-/Ausgabe-Ports umdefiniert. Das bedeutet, die CPLDs werden einmalig mit den FE3-Definitionen programmiert und danach ist das nicht ohne weiteres zu ändern. Nur mit einem Hochvolt-Programmiergerät (wie z.B. ein GALEP 4) können die Chips gelöscht und neu programmiert werden. Dazu müssen sie aber dem FE3 entnommen werden, gelöscht und neu programmiert werden und wieder in das FE3 eingesetzt werden. Ob der verwendete CPLD-Sockel die Anzahl der notwendigen Debug-Zyklen und damit die häufige Entnahme und das Wieder-Einsetzen überlebt ohne Kontaktprobleme zu bekommen und damit neue Defekte zu erzeugen, darf mit einem Fragezeichen versehen werden.
Wer das debuggen möchte, muss die verwendete Hardware-Beschreibungs-Sprache beherrschen. VHDL und Verilog helfen hier allerdings nicht weiter, da die CPLD-Logik in CUPL entwickelt wurde: eine durchaus unübliche Hardware-Beschreibungs-Sprache, die zudem veraltet ist. Zum Trost: sie ist deutlich primitiver als z.B. VHDL. Zum Entwickeln braucht man dann allerdings noch eine antike Software-Version von WinCUPL, da in den aktuellen Versionen der Atmel-Entwicklungsumgebung die Unterstützung von CUPL schon lange nicht mehr gegeben ist.
Diddl (der Entwickler) hat sich leider hier vollständig zurück gezogen, so dass auf seine Hilfe leider nicht gebaut werden kann. Wer auch immer das an seiner Stelle angehen möchte: viel Spaß! ![]()