Programmiergerät und Software für Fido1100 (CPU+ 68000)

[Rust A. (rustasian)]

Hi, ich bin auf der Suche nach einem aktuellen Programmiergerät für 
einen Fido1100 Controller von Analog Devices.

Aktuell verwende ich einen usbWiggler von OCDemon Macraigor Systems mit 
einem Commandline Tool von Innovasic.

Die Umgebung muss auf einen anderen Rechner umziehen, aber es hat noch 
niemand geschafft, die Software auf einem weiteren Rechner zum Laufen zu 
bekommen. Das Proframmiergerät selbst ist auch nicht mehr zu bekommen.

Daher suche ich nach einer Alternative, aber das gestaltet sich 
schwieriger als erwartet.

Segger scheint die CPU Architektur nicht zu unterstützen, bei OpenOCD 
hab ich auch noch keine Hinweise gefunden.

Kennt jemand diesen Controller und weiß, wie man ihn unter Windows 10/11 
programmieren kann?

[Vanye R. (vanye_rijan)]

Ich wuerde ja sagen dein FAE sollte das wissen. Aber du hast gesehen das 
der not recommended for new designs ist?

Vanye

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Rust A. schrieb:
> Kennt jemand diesen Controller und weiß, wie man ihn unter Windows 10/11
> programmieren kann?
Weil dieser Controller gar kein internes Flash hat, muss man auch nicht 
den Fido programmieren, sondern das an ihn angeschlossene Flash. Und das 
passiert z.B. indem man per JTAG passend an den Pins wackelt.

Die Alternative wäre ein Bootloader, der an Adresse 0 startet und dann 
die Software von irgendeiner Schnittstelle entgegennimmt und ins Flash 
programmiert.

Vanye R. schrieb:
> Aber du hast gesehen das der not recommended for new designs ist?
Mir wäre der auch zu alt, zu teuer und die Marktdurchdringung zu gering. 
Aber offenbar geht es hier um ein altes bestehendes Design. Da kann es 
nötig sein, einen alten, bestehenden Rechner aufzuheben und ggfs. wegen 
IT-Security nicht mehr ans Netzwerk reinzulassen.

[Rust A. (rustasian)]

Es handelt sich auch nicht um ein neues Design sondern um ein 
vorhandenes Projekt, was noch eine Weile laufen muss. Leider gibt es nur 
einen PC, auf dem die Programmierung funktioniert. Es war mir nicht 
möglich, die Treiber von der alten Software und Hardware auf einem neuen 
Rechner zu installieren. Sollte der alte Rechner die Grätsche machen hab 
ich ein Problem.

Leider habe ich das Projekt nur übernommen und nicht selbst entwickelt. 
Daher muss ich bei Null anfangen.

Ich habe eine Supportanfrage an AD gesendet, aber noch keine Antwort 
erhalten.

Sollte ich von da keine Hilfe mehr bekommen muss ich tiefer in das 
Datenblatt tauchen.

Danke zumindest für die ersten Hinweise. Jeder Tipp hilft mir weiter.

[Vanye R. (vanye_rijan)]

> Leider gibt es nur
> einen PC, auf dem die Programmierung funktioniert.

Aber da hast du doch irgendein Programmiergeraet auf dem eine 
Herstellerbezeichnung stehen muss oder?

Meine CPU32 Zeiten sind auch schon was her. Damals war das ein BDM 
Interface am Druckerport und ich musste auch noch einen notfall-Laptop 
mitschleifen und Win98 im echten DOS-Mode booten bis man den alten Kram 
beerdigen konnte. :)

Ich hoffe jedenfalls mal fuer dich das du wenigstens schon was aus dem 
USB Zeitalter hast, sonst bist du naemlich am Arsch.

Wenn USB dann kannst du mal probieren eine virtuelle Maschine mit der 
Programmierungsumgebung aufzusetzen und dort USB durchzureichen. 
Zumindest alte Xilinx-FPGA Programmer und Renesas E8 Debugger habe ich 
so bizarrerweise erfolgreich ans laufen bekommen. Haette ich selber 
nicht gedacht das dies klappt.

Vanye

[Rust A. (rustasian)]

Ich verwende hier wie gesagt aktuell ein Ding namens usbWiggler. Das ist 
ein USB2JTAG Programmer.

Ich habe aber keine Treiber und keine Inatall Dateien dafür und so weit 
mir das bekannt ist war es schon damals ein großes Problem, die Software 
zum laufen zu bekommen.

Eine Virtuelle Umgebung könnte eine Lösung sein, aber eine unschöne. Und 
wenn der Programmer defekt ist bekomme ich unter Umständen auch keinen 
Ersatz mehr. Ich hab nämlich nur den einen.

Eine andere Überlegung wäre, einen programmieren Flash Baustein 
auszulesen und die Flash Bausteine schon vor dem Einlöten zu 
programmieren. Auch keine schöne Lösung.

Am liebsten wäre mir eine Möglichkeit, einen Segger oder sowas zu 
verwenden. Aber ich habe noch keine Software gefunden, mit der ich 
programmieren könnte. Hab mich auch schon bei OpenOCD oder probe-rs 
umgeschaut. Ich hab keine Ahnung, ob ich mit probe-rs ein eigenes Target 
erstellen könnte. Aber dafür muss man sehr tief in den Datenblättern 
graben, wenn das überhaupt funktioniert.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Rust A. schrieb:
> ein USB2JTAG Programmer.
Dann hast du doch auch die passenden JTAG-Vektoren dafür und kannst 
irgendeinen anderen USB-JTAG-Player verwenden...

[Rust A. (rustasian)]

Lothar M. schrieb:
> Rust A. schrieb:
>> ein USB2JTAG Programmer.
> Dann hast du doch auch die passenden JTAG-Vektoren dafür und kannst
> irgendeinen anderen USB-JTAG-Player verwenden...

Kannst du mir genauer erklären, was du meinst bzw wie das funktioniert? 
Bin leider noch ein jtag Noob

PS: meinst du ein SVF File?

[Harald K. (kirnbichler)]

Rust A. schrieb:
> Eine Virtuelle Umgebung könnte eine Lösung sein, aber eine unschöne.

Warum? Was ist daran unschön?

[Rust A. (rustasian)]

Harald K. schrieb:
> Rust A. schrieb:
>> Eine Virtuelle Umgebung könnte eine Lösung sein, aber eine unschöne.
>
> Warum? Was ist daran unschön?

Weil an mehreren PCs ein zusätzliches OS verwaltet werden muss und weil 
das eigentliche Problem damit nicht gelöst ist. Das Hardware Problem ist 
damit auch nicht gelöst.

Das verwendete Programm scheint ausschließlich auf diesen Controller 
zugeschnitten zu sein und scheint nur diesen usbWiggler zu verwenden.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Rust A. schrieb:
> PS: meinst du ein SVF File?
Ja, das ist ausgeschrieben das "Serial Vector File", wo die Kommandos 
stehen, die an den Fido geschickt werden, damit der richtig mit den Pins 
zappelt.
- 
https://www.intel.com/content/www/us/en/programmable/quartushelp/17.0/reference/glossary/def_svf.htm

Der SVF-Player muss also "nur" den Fido erkennen (können) und dann diese 
Vektoren an den seriell rüberschieben.

[Harald K. (kirnbichler)]

Rust A. schrieb:
> Weil an mehreren PCs ein zusätzliches OS verwaltet werden muss

Ja und? Wenn es darum geht, eine musale Entwicklungsumgebung am Leben zu 
erhalten, ist das der Weg des geringsten Widerstandes. Eine VM kann man 
problemlos archivieren.

> und weil das eigentliche Problem damit nicht gelöst ist.

Naja, was ist exakt das eigentliche Problem?

Für ein (mindestens mittlerweile) exotisches museales Entwicklungssystem 
mit einer alten, heute praktisch nirgends mehr verwendeten 
Target-Architektur erwartest Du eine neue, schicke und glänzende 
Softwarealternative?

> Das Hardware Problem ist damit auch nicht gelöst.

s.o.

Im Datenblatt scheint ja einiges über das JTAG-Interface drinzustehen; 
mit etwas Aufwand Deinerseits könnte es möglich sein, das, was Deine 
alte Software mit dem alten JTAG-Interface anstellt, auch via OpenOCD 
abzuwickeln.

(Immerhin verwendest Du schon einen USB-"Wiggler" und nicht das Urmodell 
für den Frickelport ...)

[Rust A. (rustasian)]

Lothar M. schrieb:
> Ja, das ist ausgeschrieben das "Serial Vector File", wo die Kommandos
> stehen, die an den Fido geschickt werden, damit der richtig mit den Pins
> zappelt.

Dafür müsste ich das SVF File erstmal finden. Wie gesagt, alles was ich 
habe ist ein Kommandozeilentool das nicht anderes kann als diesen einen 
Controller zu programmieren. Weit und breit kein File, dass auch nur 
Ansatzweise nach SVF aussieht. Alles scheint hart in dem Tool 
programmiert zu sein.

[Rüdiger B. (rbruns)]

Rust A. schrieb:
> usbWiggler von OCDemon Macraigor System

also dieser:
https://www.jotrin.de/technology/details/macraigor-systems-usbwiggler-usb-interface
???

[Dieter S. (ds1)]

Rust A. schrieb:
>
> Dafür müsste ich das SVF File erstmal finden. Wie gesagt, alles was ich
> habe ist ein Kommandozeilentool das nicht anderes kann als diesen einen
> Controller zu programmieren. Weit und breit kein File, dass auch nur
> Ansatzweise nach SVF aussieht. Alles scheint hart in dem Tool
> programmiert zu sein.

Lade das Tool doch mal hier hoch damit man sieht womit man es zu tun 
hat.

[Rust A. (rustasian)]

Rüdiger B. schrieb:
> Rust A. schrieb:
>> usbWiggler von OCDemon Macraigor System
>
> also dieser:
> 
https://www.jotrin.de/technology/details/macraigor-systems-usbwiggler-usb-interface
> ???

Ich habe festgestellt, dass es davon verschiedene Modelle gibt. Ich habe 
hier genau genommen den U2W-ARM-20

Es gibt dann noch U2W-COP, oder U2D-COP usw. Ich habe keine Ahnung, ob 
einer von denen auch funktioniert.

Das Tool möchte ich hier nicht hochladen. Ich weiß nicht, wie meine 
Firma reagiert, wenn das rauskommt. Ich vermute aber, dass es ein 
Programm speziell für diesen einen Einsatzzweck ist und sonst nichts 
anderes kann.

Die Hardware entspricht von der Schaltung weitestgehend diesem Modul

https://www.analog.com/en/products/rapid-v2x05.html

Ich vermute tatsächlich, dass die Software einfach via Boundary Scan an 
den Ports von dem Controller wackelt, um das Flash zu programmieren. 
Keine Ahnung, wie man das nachbilden kann.

[Dieter S. (ds1)]

Rust A. schrieb:
>
> Ich vermute tatsächlich, dass die Software einfach via Boundary Scan an
> den Ports von dem Controller wackelt, um das Flash zu programmieren.
> Keine Ahnung, wie man das nachbilden kann.

Mit fast jedem beliebigen JTAG Interface bei dem man die JTAG Pins 
gezielt ansprechen kann (das können natürlich auch die entsprechenden 
FTDI Chips für JTAG).

Was genau passiert kann man herausfinden, z.B. indem man einen Logic 
Analyzer verwendet oder indem man sich das Tool genauer ansieht.

[Rust A. (rustasian)]

Die grundsätzliche Vorgehensweise ist mir klar. Man könnte einen FT232H 
oder sogar einen Tigard nehmen und mit pyjtagbs ein Programm schreiben. 
Ich weiß nur nicht, ob das nicht ausartet.

Im schlimmsten Fall muss ein Redesign auf einen TPS-1 oder so gemacht 
werden. Nur bis dahin müssen wir mit dem klar kommen, was wir haben.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Für solche speziellen Anforderungen kann ich Lauterbach empfehlen. Hast 
Du bei denen schon einmal angefragt? Der fido1100 steht zwar nicht in 
deren normaler Datenbank, aber die kennen sich eigentlich mit allen 
möglichen gebräuchlichen und exotischen Architekturen aus.

https://www.lauterbach.com/

[Dieter S. (ds1)]

Rust A. schrieb:
> Die grundsätzliche Vorgehensweise ist mir klar. Man könnte einen FT232H
> oder sogar einen Tigard nehmen und mit pyjtagbs ein Programm schreiben.
> Ich weiß nur nicht, ob das nicht ausartet.

Darum habe ich ja geschrieben dass man mit einem Logic Analyzer an den 
JTAG Pins oder einem Blick auf das Tool herausfinden kann was passiert 
und damit dann auch abschätzen kann wieviel Aufwand es wäre das Ganze 
selber zu machen. Per Boundary Scan externen Speicher anzusprechen ist 
nicht sonderlich kompliziert (falls nur das gemacht wird).

[Rust A. (rustasian)]

Andreas S. schrieb:
> Für solche speziellen Anforderungen kann ich Lauterbach empfehlen. Hast
> Du bei denen schon einmal angefragt? Der fido1100 steht zwar nicht in
> deren normaler Datenbank, aber die kennen sich eigentlich mit allen
> möglichen gebräuchlichen und exotischen Architekturen aus.
>
> https://www.lauterbach.com/

Lauterbach hatte ich zwar schon auf dem Schirm, hab aber noch nicht 
angefragt. Werde das mal nachholen. Danke fürs Anstubsen