Erstellen eines Softwaremoduls für den Programmierer XELTEK SuperPro 6100

Vorwort

In einem früheren Artikel wurde der Schutzmechanismus des XELTEK SuperPro 6100-Programmiergeräts gegen Klonen in Betracht gezogen.

In diesem Artikel wird die Erstellung eines eigenen Softwaremoduls für diesen Programmierer beschrieben, das durch eine bestimmte Änderung des Codes an alle anderen Arten von Mikroschaltungen angepasst werden kann - derzeit nicht unterstützt oder, wie in unserem Fall, nur formal angegeben.

Hintergrund

Wir hatten wieder einmal eine Aufgabe, die auf den ersten Blick ganz einfach gelöst wurde - es war notwendig, eine Kopie eines speziellen Flash-Speicherchips zu erstellen - mDOC H3 SDED5-512M.

Dieser Chip wurde vor mehr als zehn Jahren entwickelt. Hier ist das PDF (1) mit seiner Beschreibung. Unten finden Sie einen kurzen Auszug aus der russischsprachigen Ankündigung:

... msystems hat die mDOC-Familie für den Einsatz als Solid-State-Laufwerke vorbereitet ...
Die integrierte TrueFFS-Software, die mit der Verwaltung des mDOC H3-Flash-Speichers beauftragt ist, verfügt über ein eigenes Controller-Modul, das es zu einer vollständigen, eigenständigen Einheit macht, die problemlos zu einer Vielzahl von Handheld-Geräten hinzugefügt werden kann. ...

In der vom Programmierer unterstützten Liste der SuperPro 6100 wurde ein solcher Chip aufgeführt und dafür sogar der entsprechende DX5057-Adapter gefunden. Nachdem der gesamte Designer zusammengebaut und dieser Chip ausgewählt worden war, zeigte das Programm das folgende Bild mit dem mysteriösen Element „DimageMain“, dessen Beschreibung weder in der Dokumentation noch auf der Website des Entwicklers gefunden wurde.


Nachdem versucht wurde, die "DimageMain" -Operation ohne Chip im Adapter auszuführen, wurde eine Warnung über das Fehlen des Chips empfangen, und nach Bestätigung dieser Tatsache zeigte das Programm die folgenden Informationen an:


Gemessen an der Aufschrift „mDOC H3 Write Image“ ist „Image“ ein Bild, das mit diesem Programmierer auf einen Chip geschrieben werden kann. Aber wie liest man dieses Bild aus einer bereits aufgenommenen Mikroschaltung, wie löscht man es usw.?

Wenig später fand ich im Internet eine Datei (2) der Firma Dataman, die teilweise die Struktur des obigen Bildes zeigt und Software für deren Erstellung erwähnt.
Daher waren weitere Anstrengungen darauf gerichtet, nach Dienstprogrammen von M-Systems zu suchen, die im Dokument Software Utilities for TrueFFS 7.1 (3) beschrieben sind .

Die Anfrage nach technischem Support für die ehemaligen „M-Systems“, jetzt „SanDisk“, ergab kein Ergebnis - es gab einfach keine Antwort.

Im Internet konnten nur alte Dienstprogramme gefunden werden, die die Version von H3-Chips nicht unterstützen. Das vollständige SDK von SanDisk wurde ebenfalls nicht gefunden, nur seine „Fragmente“ (5) im Hinblick auf die Implementierung eines Treibers für Linux.

Während wir die gesammelten Informationen untersuchten, erregte die folgende Zeile die Aufmerksamkeit der Dataman-Datei: „Bilddateien können mit dem SanDisk Docshell-Dienstprogramm oder PG4UW erstellt werden.“

Die SanDisk Docshell-Dienstprogramme fanden sich in keiner Weise wieder, daher musste ich herausfinden, wie PG4UW (4) mit diesem Chip funktioniert. Sie haben nicht das gesamte SanDisk SDK in ihre Software eingebettet, sondern ein Plug-In mit exportierten Methoden erstellt, die für das Funktionieren der TrueFFS-Dienstprogramme erforderlich sind und dann von ihrem Programm aufgerufen werden.
Wir werden den gleichen Weg gehen.

Erstellen Sie Ihr eigenes Softwaremodul

Hier ist ein Haftungsausschluss, nämlich dass der Autor keine Verantwortung für die Verwendung der Materialien in diesem Artikel durch Sie trägt.
Mit anderen Worten - nur Sie selbst sind für Ihre Handlungen verantwortlich, die durch die Einarbeitung in dieses Material ausgelöst werden können.

Wir sind uns einig, wie im vorherigen Artikel, den Programmierer-Programmierer von SuperPro 6100 einfach "Software" zu nennen, und der Computer, auf dem dieses Programm arbeitet, ist "Host". Jetzt haben wir ein anderes Programm, das im Programmierer selbst funktioniert. Wir werden es das "Softwaremodul" nennen.

Das Handbuch Software Utilities for TrueFFS 7.1 (3) beschreibt die von den DOCSHELL-Dienstprogrammen implementierten Funktionen, die in die folgenden vier Kategorien fallen:

• DFORMAT - Dienstprogramme zum Formatieren eines mDOC-Geräts.
• DINFO - Dienstprogramme zum Abrufen einer Vielzahl von Informationen über das mDOC-Gerät und die darauf vorhandenen Abschnitte.
• DIMAGE - Dienstprogramme zum Lesen, Schreiben und Vergleichen des Bild-mDOC-Geräts.
• SPLITIMAGE - Dienstprogramme zum Teilen des mDOC-Gerätebilds in Teile.

DOCSHELL-Dienstprogramme waren für die Befehlszeile vorgesehen, daher wurde die Schnittstelle für die Kommunikation mit dem Plugin DOCSHELL.dll unter Verwendung des gleichen Textbefehlsmechanismus implementiert.
Bevor Sie mit der Kommunikation mit „DOCSHELL.dll“ beginnen, müssen Sie jede der exportierten Methoden aufrufen und ihnen Zeiger auf die in der Software implementierten Funktionen für den physischen Austausch mit dem mDOC-Chip übergeben. Dies sind Schreiben und Lesen (in verschiedenen Modifikationen) sowie Methoden zum Empfangen von Textnachrichten über den Fortschritt der aktuellen Vorgänge und Methoden zum Arbeiten mit Bilddateien.

Eine der exportierten mainEntry-Methoden als Eingabeargument
akzeptiert eine ASCIIZ-Zeichenfolge - den Befehl, der im Handbuch Software Utilities for TrueFFS 7.1 (3) beschrieben ist .

Der Parser in "DOCSHELL.dll" verarbeitet den empfangenen Befehl und ruft abhängig vom Befehl und seinen Argumenten die eine oder andere Methode von der Hauptprogrammiersoftware unter Verwendung des Zeigers auf, der während der anfänglichen Initialisierung empfangen wurde.

Software für den Programmierer haben wir uns entschlossen, Ihre eigene zu schreiben. Dieser Ansatz ersparte uns einerseits das „Graben“ in den Originaldateien, um die Vereinbarungen über den Informationsaustausch zwischen dem Host und dem Programmierer einzuhalten, und erleichterte andererseits den Debugging-Prozess erheblich, der es in einigen Aspekten unmöglich machte, wenn das Modul in die ursprüngliche Software integriert wurde oder extrem schwierig.

Die native Benutzeroberfläche für den Programmierer wurde in C # in Visual Studio 2017 geschrieben. Quellen (6) sind enthalten.

Natürlich war die Funktionalität an erster Stelle, so dass von einem Einrasten des Erscheinungsbilds sowie des Textes des Quellcodes selbst keine Rede war. Daher ist das minimalistische „Design“ des Programms wie folgt.


Oben im Hauptfenster (und nur im Fenster) befindet sich ein Menü, für dessen Schaltflächen Sie beliebige Funktionen zuweisen können. Der Menüpunkt „XILINX“ wird später beschrieben.

Unten sind zwei Fenster. Der obere Teil zeigt Nachrichten an, die vom Programm an das Plugin "DOCSHELL.dll" gesendet und von diesem empfangen wurden.

Im unteren Fenster können Sie die gewünschten Befehle eingeben und in der entsprechenden Zeile doppelklicken.

Wenn das Programm gestartet wird, werden einige Befehle darin angezeigt.

Wenn Sie plötzlich mit einem echten Chip arbeiten, seien Sie vorsichtig, denn Keine Warnungen, dass Sie beim Formatieren usw. alle Daten verlieren könnten. Das Programm ist nicht implementiert.

Die Datei "DOCSHELL.dll" befindet sich im Verzeichnis mit dem installierten Programm PG4UW (4) von "Dataman" (möglich von "Elnec").

Um eine DLL eines Drittanbieters in Ihrem Programm verwenden zu können, benötigen Sie eine Header-Datei mit einer Beschreibung der exportierten Methoden und ihrer Argumente. Aufgrund seiner Abwesenheit musste ich diese Informationen selbst wiederherstellen. Die Methoden für eine solche Wiederherstellung gehen über den Rahmen dieses Artikels hinaus, sodass die Argumente der exportierten Methoden in den angehängten Quellen zu finden sind.

Mit der Benutzeroberfläche in Bezug auf die Interaktion mit dem Plugin ist die Sache etwas klarer geworden. Jetzt können Sie mit der Implementierung der Kommunikation mit der Mikroschaltung auf physikalischer Ebene fortfahren, um die vom Plugin empfangenen Lese- / Schreibbefehle von / zu mDOC ausführen zu können.

Das Programmmodul für den Programmierer wurde in der IDE "IAR Embedded Workbench for ARM" in C geschrieben. Quellen (7) sind beigefügt.

Das Debuggen wurde mit dem JTAG J-Link-Debugger durchgeführt, der über einen an der Seite des Gehäuses angebrachten JTAG-Anschluss mit dem Programmierer verbunden und über ein Flachkabel mit dem Motherboard verbunden war.

Der JTAG-Debugger J-Link v9 wurde auf Aliexpress gekauft. Die mit der „IAR Embedded Workbench for ARM“ installierten Treiber funktionieren hervorragend damit, und sogar das Aktualisieren der nativen Firmware von SEGGER war erfolgreich.


Strukturell besteht der Programmierer aus acht übereinander angeordneten und durch Verbinder miteinander verbundenen Karten.


Einstellbare DC-DC-Wandler befinden sich auf der untersten Platine, um mehrere Spannungen zu erzeugen, die für die Arbeit mit verschiedenen Speichermikroschaltungen erforderlich sind.
Darüber befindet sich ein Motherboard, auf dem der ATMEL AT91SAM9G20 ARM-Mikrocontroller, SDRAM, SPI FLASH mit Firmware, ID-Chip AE801 mit Programmierermodell und Seriennummer, USB-Chip ISP1582, Digital-Analog-Wandler TLC7226 für das Spannungsmanagement von DC-DC-Wandlern, eine Reihe anderer Chips und externer Anschlüsse zum Anschließen eines Netzteils und ein USB-Kabel zum Anschließen an den Host.

Auf der dritten unteren Platine befindet sich der XILINX XC2S50E-Chip, der die Beine des Chips auf dem Adapter steuert, der während des Lese- / Schreibvorgangs usw. mit dem Programmierer verbunden ist.
Auf den anderen fünf Karten befinden sich nacheinander geladene Register und Baugruppen mit Transistorschaltern, die an ihre Ausgänge angeschlossen sind, über die es möglich ist, Mikroschaltungen an diesen durch Gleichspannungswandler gebildeten Zweigen des Adapters anzulegen.
einschließlich der "Erde". Da die Register, die die Transistorschlüssel steuern, nacheinander geladen werden und die Anzahl der gesteuerten Zweige im Adapter 144 erreichen kann, dauert das Laden aller Schlüsselblöcke eine beträchtliche Zeit. Daher werden mit Hilfe von Transistorschaltern nur statische Pegel in die Mikroschaltung eingespeist: Masse, Leistung usw. Und mit XILINX - dynamisch: Adressen, Daten, CS, OE, RD, WR usw.

Um weiter voranzukommen, war mindestens ein Mittel zum Erstellen einer Firmware für den XILINX XC2S50E-Mikroschaltkreis und ein Schaltplan erforderlich, wenn nicht der gesamte Programmierer, dann zumindest ein Teil davon CPU-FPGA-Adapter-Sockel.

Für die IDE für XILINX Spartan-IIE musste ich die alte Version von ISE 10.1 verwenden, weil Alle nachfolgenden IDEs unterstützen das Spartan-II-FPGA-Modell nicht.

Die Situation mit dem Schaltplan erwies sich als komplizierter. Um die für uns interessanten Verbindungen zu identifizieren, mussten wir den U4- und XILINX U12-Prozessor von den Karten entfernen, um Zugang zu den Pads unter ihren BGA-Gehäusen zu erhalten, weil Nicht alle haben einen Schalter auf der Rückseite.
Der Host kommuniziert mit dem Programmierer über USB über mehrere Endpunkte (Endpunkte). Der Host fungiert immer als Host. Über einen der Endpunkte sendet der Host einen Befehl an den Programmierer und erhält über diesen eine Bestätigung.
durch einen anderen tauschen sie Daten miteinander aus.

Das Parsen von Befehlen vom Host im Programmmodul wird in der Methode USB_ReceiveBuf_EP1RX_Parse () ausgeführt.

Das Befehlspaket wird durch die CMD_PROG-Struktur beschrieben und besteht aus mehreren Feldern. Wenn das Cmd-Feld 1 enthält, ist dies ein Befehl zum Arbeiten mit der Mikroschaltung, und das ProgProcNum-Feld ist in diesem Fall der Index im Array _progProcedures von PROG_PROC-Strukturen, in einem dieser Felder ist ein Zeiger auf den auszuführenden Befehl gespeichert.

Im Verzeichnis mit dem installierten Programm "SUPERPRO 6100N" befindet sich ein Unterverzeichnis "\ lib". Es mit der Erweiterung "* .bin" speichert XILINX-Firmware-Dateien für alle vom Programmierer unterstützten Arten von Chips. Darunter befinden sich zwei universelle Firmware zur Überprüfung des Kontakts der Beine der Mikroschaltung mit den Kontakten der Buchsen im Adapter.

Dies ist "GENERAL ~ .BIN" mit einem internen Pull-up für alle XILINX-Pull-up-Beine und "GENERAL_.BIN" mit einem internen Pull-down-Pull.

Die Überprüfung des Kontakts der Mikroschaltungsbeine erfolgt in der SOCKET_CkeckInsertIC () -Methode des Softwaremoduls wie folgt.

Zunächst wird die Firmware „GENERAL_.BIN“ in XILINX geladen und mit ihrer Hilfe werden alle an den Sockel angeschlossenen FPGA-Zweige für die Ausgabe konfiguriert und mit logischer „1“ versorgt. Dann wird wiederum jeder FPGA-Zweig für die Eingabe neu konfiguriert, eine logische Ebene wird daraus gelesen und dann wird wieder "1" an diesen Zweig ausgegeben.

Wenn das Mikroschaltungsbein elektrischen Kontakt mit dem entsprechenden Sockelbein hat, sollte „1“ daraus abgelesen werden (durch die internen Schutzdioden des Mikroschaltkreises von allen anderen Beinen). Und wenn kein Kontakt besteht, wird aufgrund der Tatsache, dass alle FPGA-Pins in den Boden gezogen sind, „0“ von diesem Eingang gelesen. Danach wird ein Array von auf diese Weise gelesenen logischen Ebenen an den Host gesendet und dort verarbeitet. Als nächstes wird die Ausführung der angegebenen Operation fortgesetzt, oder es wird eine Meldung über die Nicht-VKontakte der entsprechenden Schenkel der Mikroschaltung in der Buchse angezeigt.
Nach erfolgreichem Bestehen dieses Tests sendet der Host die Firmware für XILINX, die dem im Adapter installierten Chip entspricht, an den Programmierer.

Durch das Kompilieren eines Programms für FPGA in ISE 10.1 (sequentielle Ausführung von Syntheseprozeduren (Synthesize), Implementierung eines Designs (Implement Design) und Generierung von Programmierdateien (Generate Programming File)) wird eine binäre Konfigurationsdatei „xeltek.bin“ mit 78756 Bytes im Projektverzeichnis erstellt. Dazu müssen in den Eigenschaften des Prozesses "Programmierdatei generieren" im Fenster "Prozesse" in der Kategorie "Allgemeine Optionen" zwei Optionen festgelegt werden: "Bitdatei erstellen" und "Bibary-Konfigurationsdatei erstellen".

Es ist nicht bekannt, aus welchen Gründen, aber XELTEK-Programmierer haben beschlossen, die so erhaltenen Dateien zu ändern, indem sie alle Bits in jedem Byte spiegeln.

Wenn Sie aus irgendeinem Grund Ihre eigene Datei auf diese Weise "spiegeln" oder die Datei aus dem Verzeichnis "\ lib" zurück in die normale Ansicht "spiegeln" müssen, befindet sich in der Software im Menü "XILINX" zu diesem Zweck der Punkt "Bitstream Converter" (am Ende des Namens) Die resultierende Datei ist unterstrichen.

Um mit dem SDED5-Chip auf physischer Ebene zu arbeiten, sind im Softwaremodul die folgenden vier Methoden implementiert:

- PROGPROC_FLWRITE_IO_WORD () - Zeichnet ein Wort (16 Bit) an der angegebenen Adresse auf
- PROGPROC_FLREAD_IO_WORD () - Lesen Sie das Wort (16 Bit) an der angegebenen Adresse
- PROGPROC_hal_blk_write_nor () - Schreiben Sie einen oder mehrere Sektoren (jeweils 512 Byte) an die angegebene Adresse
- PROGPROC_hal_blk_read_nor () - Liest einen oder mehrere Sektoren (jeweils 512 Byte) an der angegebenen Adresse

Für die Interaktion mit dem FPGA XILINX in unserer Firmware haben wir vier Register identifiziert (E / A-Ports, beschrieben in der Datei common.h für ARM-Quellen).

- _IC_ADDR (0x30000010)
- _IC_DATA (0x30000012)
- _IC_CTRL (0x30000014) // Out: 0 - WE, 1 - 0E, 2 - CE, 3 - RSTIN; In: 0 - BESETZT
- _IC_ENABLE (0x30000016) // In: 7 - Arbeitserlaubnis (0 - aktiv, 1 - alle Beine an der Steckdose in Z)

_IC_ADDR und _IC_DATA sind 16-Bit-Adress- und Datenregister für den programmierbaren SDED5-Chip.
_IC_CTRL - 8-Bit-Steuerregister, über das die WE-, OE-, CE- und RSTIN-Signale gesetzt und das BUSY-Signal von SDED5 gelesen werden.

Die ursprünglichen Softwaremodule verwenden Adressen von 0x30000000 bis 0x3000000E, um mit FPGAs zu kommunizieren. CPLD mit der XELTEK-Beschriftung ist als Adressdecoder im Programmierer installiert. Da wir die Firmware nicht kennen, haben wir Adressen von 0x30000010 verwendet, um die Wahrscheinlichkeit unerwarteter Konsequenzen zu verringern, die sich aus der Darstellung der Verhaltenslogik eines anderen bei Verwendung von „Standard“ -Adressen ergeben.

Nach dem Laden der Firmware in das FPGA befinden sich alle FPGA-Ausgänge, die an die Schenkel der Mikroschaltung im Sockel angeschlossen sind, im Z-Zustand. Um damit arbeiten zu können, müssen Sie die Auflösung aktivieren, indem Sie Null in das siebte Bit des Registers _IC_ENABLE schreiben.

Der Algorithmus des gesamten Systems kann wie folgt aussehen.

1. Nach dem Starten der Software auf dem Host wird geprüft, ob eine Verbindung zum Programmierer über USB besteht, und die entsprechende Meldung wird in der Statusleiste unten im Hauptfenster angezeigt
   (Der Programmierer kann nach dem Start des Programms angeschlossen werden).
2. Der Benutzer wählt den Chip-Typ aus, mit dem er arbeiten möchte.
3. In der Datenbank (im einfachsten Fall nur in der Datei) entspricht der ausgewählte Mikroschaltkreis dem erforderlichen Adaptertyp, und an den Programmierer wird eine Anfrage nach dem darin installierten Adaptertyp gesendet.
4. Der Programmierer fragt den Adapter nach seinem Typ und sendet diese Informationen an den Host zurück, wo diese Informationen mit denen in der Datenbank verglichen werden. Wenn die Adaptertypen übereinstimmen, wird die Arbeit fortgesetzt.
5. Für jeden in der Software ausgewählten Mikrokreistyp sollte ein entsprechendes Menü mit den für diesen Mikrokreis verfügbaren Befehlen angezeigt werden (Lesen, Schreiben, Überprüfen auf Sauberkeit, Vergleich usw.).
6. Wenn Sie einen Menüpunkt für die Arbeit mit der Mikroschaltung auswählen, wird der entsprechende Befehl an den Programmierer gesendet. Danach überprüft der Programmierer zuerst den elektrischen Kontakt der Kontakte der Buchsen mit den Beinen der Mikroschaltung und führt diesen Befehl dann erfolgreich aus, wenn er erfolgreich ist.

In den dem Artikel beigefügten Quellcodes werden zur Vereinfachung der Aufgabe keine Punkte vom zweiten bis zum fünften einschließlich implementiert.

Zusammenfassung

Wir standen nicht vor der Aufgabe, das Softwaremodul in die ursprüngliche Software zu integrieren.
Daher erhebt das in diesem Artikel beschriebene Material keinen Anspruch auf vollständige Lösung.
Wir hoffen, dass die hier präsentierten Informationen für eine bestimmte Kategorie von Lesern nützlich sind. Nach bestem Wissen und Gewissen und Verfügbarkeit der Freizeit werden wir versuchen, Ihre Fragen zu beantworten.

Vielen Dank für Ihr Interesse!

Ressourcen

1. PDF - mDOC H3 Embedded Flash Drive (EFD) mit eingebetteter TrueFFS Flash Management Software
2. PDF - Programmieren von mDOC H3-Flash-Speichern mit Dataman-Geräteprogrammierern
3. PDF - Software_Utilities_TrueFFS_7.1
4. Dataman Control Software - PG4UW
5. Implementierung des mDOC H3-Treibers für Linux (Leistung wurde nicht getestet)
6. Host-Programmierer-Quelldateien (Visual Studio 2017).
7. Quelldateien des Softwaremoduls (IAR Embedded Workbench für ARM v8.30.1).
8. Quelldateien für FPGA XILINX XC2S50E (XILINX ISE 10.1).