Création d'un module logiciel pour le programmateur XELTEK SuperPro 6100

Préface

Dans un article précédent, le mécanisme de protection du programmateur XELTEK SuperPro 6100 contre le clonage a été examiné.

Cet article décrira la création de son propre module logiciel pour ce programmeur, qui, par une certaine modification du code, peut être adapté pour fonctionner avec tout autre type de microcircuits - actuellement non pris en charge ou, comme dans notre cas, déclaré uniquement formellement.

Contexte

Une fois de plus, nous avons eu une tâche qui, à première vue, a été résolue tout simplement - il était nécessaire de faire une copie d'une puce de mémoire flash spécialisée - mDOC H3 SDED5-512M.

Cette puce a été développée il y a plus de dix ans. Voici le pdf (1) avec sa description. Vous trouverez ci-dessous un court extrait de l'annonce en russe:

... msystems a préparé la famille mDOC pour une utilisation en tant que disques SSD ...
Le logiciel TrueFFS intégré, qui est chargé de gérer la mémoire flash mDOC H3, exécute son propre contrôleur de module, qui le transforme en une unité complète et autonome, facilement ajoutée à une variété d'appareils portables. ...

Dans la liste des SuperPro 6100 pris en charge par le programmeur, une telle puce a été répertoriée et a même trouvé l'adaptateur DX5057 correspondant. Mais après avoir assemblé l'ensemble du concepteur et choisi cette puce, le programme a montré l'image suivante avec l'élément mystérieux "DimageMain", dont la description n'a été trouvée ni dans la documentation ni sur le site Web du développeur.


Ayant tenté d'effectuer l'opération «DimageMain» sans puce dans l'adaptateur, un avertissement a été reçu concernant son absence, et après confirmation de ce fait, le programme a affiché les informations suivantes:


A en juger par l'inscription «mDOC H3 Write Image», «Image» est une image qui peut être écrite sur une puce à l'aide de ce programmateur. Mais comment lire cette image à partir d'un microcircuit déjà enregistré, comment l'effacer, etc.?

Un peu plus tard sur Internet, j'ai trouvé un fichier (2) de la société Dataman, qui montre partiellement la structure de l'image ci-dessus et mentionne le logiciel pour sa création.
Ainsi, de nouveaux efforts visaient à rechercher des utilitaires dans M-Systems décrits dans le document Software Utilities for TrueFFS 7.1 (3) .

La demande d'assistance technique des anciens «M-Systems», aujourd'hui «SanDisk», n'a pas donné de résultat - il n'y a tout simplement pas de réponse.

Sur Internet, il n'a été possible de trouver que d'anciens utilitaires ne prenant pas en charge la version des puces H3. Le SDK complet de SanDisk n'a pas non plus été trouvé, seulement ses «fragments» (5) en termes d'implémentation d'un pilote pour Linux.

Pendant que nous étudiions les informations accumulées, la ligne suivante a attiré l'attention du fichier Dataman: "Les fichiers image peuvent être créés avec l'utilitaire SanDisk Docshell ou PG4UW."

Les utilitaires SanDisk Docshell ne se sont pas trouvés en aucune façon, j'ai donc dû comprendre comment PG4UW (4) fonctionnait avec cette puce. Ils n'ont pas intégré l'intégralité du SDK SanDisk dans leur logiciel, mais ont créé un plug-in avec les méthodes exportées nécessaires au fonctionnement des utilitaires TrueFFS, qui sont ensuite appelées à partir de leur programme.
Nous irons de la même façon.

Création de votre propre module logiciel

Voici un déni de responsabilité, à savoir que l'auteur ne porte aucune responsabilité pour toute utilisation par vous des matériaux de cet article.
En d'autres termes - vous seul serez responsable de vos actions, ce qui peut vous inciter à vous familiariser avec ce matériel.

Nous convenons, comme dans l'article précédent, d'appeler le programmeur programmeur de SuperPro 6100 simplement «logiciel», et l'ordinateur sur lequel ce programme fonctionne est «hôte». Maintenant, nous avons un autre programme qui fonctionne dans le programmeur lui-même. Nous l'appellerons le «module logiciel».

Le manuel Software Utilities for TrueFFS 7.1 (3) décrit les fonctions implémentées par les utilitaires DOCSHELL, qui entrent dans les quatre catégories suivantes:

• DFORMAT - utilitaires pour formater un périphérique mDOC.
• DINFO - utilitaires pour obtenir une variété d'informations sur le périphérique mDOC et les sections qui s'y trouvent.
• DIMAGE - utilitaires pour lire, écrire et comparer le périphérique image mDOC.
• SPLITIMAGE - utilitaires pour diviser l'image du périphérique mDOC en parties.

Les utilitaires DOCSHELL étaient destinés à la ligne de commande, par conséquent, l'interface de communication avec le plug-in DOCSHELL.dll a été implémentée à l'aide du même mécanisme de commande de texte.
Avant de commencer la communication avec «DOCSHELL.dll», il est nécessaire d'appeler chacune des méthodes exportées et de leur passer des pointeurs vers les fonctions implémentées dans le logiciel pour un échange physique avec la puce mDOC. Il s'agit de l'écriture et de la lecture (en plusieurs modifications), ainsi que des méthodes de réception de messages texte sur la progression des opérations en cours et des méthodes de travail avec les fichiers image.

L'une des méthodes mainEntry exportées comme argument d'entrée
accepte une chaîne ASCIIZ - la commande décrite dans le manuel Software Utilities for TrueFFS 7.1 (3) .

L'analyseur à l'intérieur de "DOCSHELL.dll" traite la commande reçue et, selon la commande et ses arguments, appelle l'une ou l'autre méthode à partir du logiciel de programmation principal à l'aide du pointeur reçu lors de l'initialisation initiale.

Logiciel pour le programmeur, nous avons décidé d'écrire le vôtre. Cette approche, d'une part, nous a évité de «creuser» dans les fichiers d'origine pour respecter les accords sur l'échange d'informations entre l'hôte et le programmeur, et d'autre part, elle a grandement facilité le processus de débogage, ce qui, si le module était intégré au logiciel d'origine, rendait impossible à certains égards ou extrêmement difficile.

L'interface utilisateur native du programmeur a été écrite en C # dans Visual Studio 2017. Les sources (6) sont incluses.

Bien sûr, la fonctionnalité était en premier lieu, il n'était donc pas question de claquer l'apparence, ainsi que le texte du code source lui-même. Par conséquent, la «conception» minimaliste du programme est la suivante.


En haut de la fenêtre principale (et uniquement) se trouve un menu pour les boutons dont vous pouvez attribuer des fonctions arbitraires. L'élément de menu «XILINX» sera décrit plus loin.

Voici deux fenêtres. La partie supérieure affiche les messages envoyés du programme au plugin "DOCSHELL.dll" et reçus de celui-ci.

Dans la fenêtre du bas, vous pouvez taper les commandes dont vous avez besoin et double-cliquer dessus dans la ligne correspondante.

Au démarrage du programme, certaines commandes y seront affichées.

Si vous vous mettez soudainement au travail avec une vraie puce - faites attention, car aucun avertissement que vous risquez de perdre toutes les données lors du formatage, etc. Le programme n'est pas mis en œuvre.

Le fichier «DOCSHELL.dll» se trouve dans le répertoire avec le programme PG4UW (4) installé depuis «Dataman» (il est possible depuis «Elnec»).

Pour pouvoir utiliser une DLL tierce dans votre programme, vous avez besoin d'un fichier d'en-tête avec une description des méthodes exportées et de leurs arguments. En raison de son absence, j'ai dû récupérer moi-même ces informations. Les méthodes pour une telle récupération sont au-delà de la portée de cet article, donc les arguments des méthodes exportées peuvent être trouvés dans les sources jointes.

Avec l'interface utilisateur en termes d'interaction avec le plugin, la question est devenue plus claire. Vous pouvez maintenant procéder à l'implémentation de la communication avec le microcircuit au niveau physique afin de pouvoir exécuter les commandes de lecture / écriture de / vers mDOC reçues du plugin.

Le module du programme pour le programmeur a été écrit en langage C dans l'IDE "IAR Embedded Workbench for ARM". Les sources (7) sont jointes.

Son débogage a été effectué à l'aide du débogueur JTAG J-Link, connecté au programmateur via un connecteur JTAG monté sur le côté du boîtier et connecté à la carte mère par un câble plat.

Le débogueur JTAG J-Link v9 a été acheté sur Aliexpress. Les pilotes installés avec «IAR Embedded Workbench for ARM» fonctionnent à merveille avec lui, et même la mise à jour du firmware natif de SEGGER a réussi.


Structurellement, le programmateur est constitué de huit cartes situées l'une au-dessus de l'autre et reliées entre elles par des connecteurs.


Les convertisseurs DC-DC réglables sont situés sur la carte la plus basse pour générer plusieurs tensions nécessaires pour travailler avec divers microcircuits de mémoire.
Au-dessus se trouve une carte mère sur laquelle le microcontrôleur ATMEL AT91SAM9G20 ARM, SDRAM, SPI FLASH avec firmware, puce ID AE801 avec modèle de programmateur et numéro de série, puce USB ISP1582, convertisseur numérique-analogique TLC7226 pour la gestion de la tension des convertisseurs DC-DC, un certain nombre d'autres puces et connecteurs externes pour connecter une alimentation et un câble USB pour se connecter à l'hôte.

Sur la troisième carte inférieure se trouve la puce XILINX XC2S50E, qui contrôle les jambes de la puce sur l'adaptateur connecté au programmateur pendant les procédures de lecture / écriture, etc.
Sur les cinq autres cartes se trouvent des registres et des ensembles chargés séquentiellement avec des commutateurs à transistors connectés à leurs sorties, à travers lesquels il est possible d'appliquer des microcircuits à ces jambes de l'adaptateur formé par des convertisseurs de tension DC-DC,
y compris la "terre". Étant donné que les registres contrôlant les clés de transistor sont chargés séquentiellement et que le nombre de branches contrôlées dans l'adaptateur peut atteindre 144, il faut beaucoup de temps pour charger tous les blocs de clés. Par conséquent, à l'aide de commutateurs à transistors, seuls les niveaux statiques sont transmis au microcircuit: masse, alimentation, etc. Et avec XILINX - dynamique: adresses, données, CS, OE, RD, WR, etc.

Pour aller plus loin, il fallait, au minimum, avoir un moyen de créer un firmware pour le microcircuit XILINX XC2S50E et un schéma de circuit, sinon de tout le programmeur, alors au moins une partie CPU - FPGA - adaptateur - socket.

Quant à l'IDE pour XILINX Spartan-IIE, j'ai dû utiliser l'ancienne version d'ISE 10.1, car tous les IDE suivants ne prennent pas en charge le modèle FPGA Spartan-II.

La situation avec le schéma de circuit s'est avérée plus compliquée. Pour identifier les composés qui nous intéressent, nous avons dû «retirer» les processeurs U4 et XILINX U12 des cartes pour accéder aux pads sous leurs boîtiers BGA, car ils n'ont pas tous un interrupteur vers l'arrière.
L'hôte communique avec le programmateur via USB via plusieurs points d'extrémité (points d'extrémité). L'hôte agit toujours en tant qu'hôte. Par l’un des points de terminaison, l’hôte envoie une commande au programmeur et, à travers lui, reçoit une confirmation,
à travers un autre, ils échangent des données entre eux.

L'analyse des commandes de l'hôte dans le module de programme est effectuée dans la méthode USB_ReceiveBuf_EP1RX_Parse ().

Le package de commandes est décrit par la structure CMD_PROG et se compose de plusieurs champs. Si le champ Cmd contient 1, il s'agit d'une commande pour travailler avec le microcircuit et le champ ProgProcNum dans ce cas est l'index dans le tableau _progProcedures des structures PROG_PROC, dans l'un des champs, un pointeur vers la commande à exécuter est stocké.

Dans le répertoire avec le programme installé "SUPERPRO 6100N", il y a un sous-répertoire "\ lib". Il avec l'extension "* .bin" stocke les fichiers du firmware XILINX pour tous les types de puces pris en charge par le programmeur. Parmi eux, il existe deux micrologiciels universels pour vérifier le contact des jambes du microcircuit avec les contacts des prises de l'adaptateur.

Il s'agit de «GENERAL ~ .BIN» avec une traction interne pour toutes les jambes de traction XILINX et «GENERAL_.BIN» avec une traction interne vers le bas.

La vérification du contact des jambes de microcircuit est effectuée dans la méthode SOCKET_CkeckInsertIC () du module logiciel comme suit.

Tout d'abord, le firmware «GENERAL_.BIN» est chargé dans XILINX et avec son aide, toutes les branches FPGA connectées au socket sont configurées pour la sortie et le «1» logique leur est fourni. Puis, à son tour, chaque branche FPGA est reconfigurée en entrée, un niveau logique est lu à partir de celle-ci, puis "1" est de nouveau émis vers cette branche.

Si le pied de microcircuit a un contact électrique avec le pied de prise correspondant, alors «1» doit être lu à partir de celui-ci (à travers les diodes de protection internes du microcircuit de tous les autres pieds). Et en l'absence de contact, du fait que toutes les broches FPGA sont tirées dans le sol, «0» sera lu sur cette entrée. Après cela, un tableau de niveaux logiques lus de cette manière est envoyé à l'hôte et y est traité. Ensuite, l'exécution de l'opération spécifiée se poursuit, ou un message s'affiche sur le non-contact des jambes correspondantes du microcircuit dans la prise.
Après avoir réussi ce test, l'hôte envoie au programmeur le micrologiciel pour XILINX correspondant à la puce installée dans l'adaptateur.

La compilation d'un programme pour FPGA dans ISE 10.1 (exécution séquentielle de procédures de synthèse (Synthesize), implémentation d'une conception (Implement Design) et génération de fichiers de programmation (Generate Programming File)) crée un fichier de configuration binaire "xeltek.bin" de 78756 octets dans le répertoire du projet. Pour cela, dans les propriétés du processus «Générer un fichier de programmation» dans la fenêtre «Processus» de la catégorie «Options générales», deux options doivent être définies: «Créer un fichier bit» et «Créer un fichier de configuration bibary».

On ne sait pas pour quelles raisons, mais les programmeurs XELTEK ont décidé de modifier les fichiers ainsi obtenus en mettant en miroir tous les bits de chaque octet.

Si, pour quelque raison que ce soit, vous devez «mettre en miroir» votre propre fichier de cette manière, ou «mettre en miroir» le fichier du répertoire «\ lib» vers la vue normale, dans le logiciel du menu «XILINX», il y a à cet effet l'élément «Bitstream Converter» (à la fin du nom le fichier résultant est souligné).

Pour travailler avec la puce SDED5 au niveau physique, les quatre méthodes suivantes sont implémentées dans le module logiciel:

- PROGPROC_FLWRITE_IO_WORD () - enregistrer un mot (16 bits) à l'adresse indiquée
- PROGPROC_FLREAD_IO_WORD () - lire le mot (16 bits) à l'adresse indiquée
- PROGPROC_hal_blk_write_nor () - écrire un ou plusieurs secteurs (512 octets chacun) à l'adresse spécifiée
- PROGPROC_hal_blk_read_nor () - lire un ou plusieurs secteurs (512 octets chacun) à l'adresse spécifiée

Pour interagir avec le FPGA XILINX dans notre micrologiciel, nous avons identifié quatre registres (ports d'E / S, décrits dans le fichier common.h pour les sources ARM).

- _IC_ADDR (0x30000010)
- _IC_DATA (0x30000012)
- _IC_CTRL (0x30000014) // Sortie: 0 - WE, 1 - 0E, 2 - CE, 3 - RSTIN; Dans: 0 - OCCUPÉ
- _IC_ENABLE (0x30000016) // In: 7 - Autorisation de travail (0 - actif, 1 - toutes les jambes sur le socket en Z)

_IC_ADDR et _IC_DATA sont des registres d'adresse et de données 16 bits pour la puce programmable SDED5;
_IC_CTRL - Registre de contrôle à 8 bits à travers lequel les signaux WE, OE, CE et RSTIN sont définis et le signal BUSY est lu à partir de SDED5.

Les modules logiciels d'origine utilisent des adresses de 0x30000000 à 0x3000000E pour communiquer avec les FPGA. CPLD avec l'inscription XELTEK est installé comme décodeur d'adresse dans le programmeur, et comme nous ne connaissons pas son firmware, nous avons utilisé des adresses de 0x30000010 juste au cas où pour réduire la probabilité de conséquences inattendues de manifester la logique de comportement de quelqu'un d'autre lors de l'utilisation d'adresses "standard".

Après avoir chargé son micrologiciel dans le FPGA, toutes les sorties FPGA connectées aux jambes du microcircuit dans la prise sont à l'état Z et pour commencer à travailler avec, vous devez activer la résolution en écrivant de zéro au septième bit du registre _IC_ENABLE.

L'algorithme de l'ensemble du système peut se présenter comme suit.

1. Après avoir démarré le logiciel sur l'hôte, il vérifie s'il y a une connexion au programmateur via USB et affiche le message correspondant dans la barre d'état en bas de la fenêtre principale
   (le programmateur peut être connecté après le démarrage du programme).
2. L'utilisateur sélectionne le type de puce avec lequel il a l'intention de travailler.
3. Dans la base de données (dans le cas le plus simple, juste dans le fichier), le microcircuit sélectionné correspond au type d'adaptateur requis et une demande est envoyée au programmeur pour le type d'adaptateur installé dans celui-ci.
4. Le programmeur demande à l'adaptateur son type et renvoie ces informations à l'hôte, où ces informations sont comparées à celles trouvées dans la base de données, et si les types d'adaptateurs correspondent, le travail se poursuit.
5. Pour chaque type de microcircuit sélectionné dans le logiciel, un menu correspondant doit être affiché avec les commandes disponibles pour ce microcircuit (lecture, écriture, vérification de propreté, comparaison, etc.).
6. Lorsque vous sélectionnez un élément de menu pour travailler avec le microcircuit, la commande correspondante est envoyée au programmateur, après quoi le programmeur vérifie d'abord le contact électrique des contacts de la prise avec les jambes du microcircuit, puis, en cas de succès, exécute cette commande.

Dans les codes sources joints à l'article, pour simplifier la tâche, les points du deuxième au cinquième inclus ne sont pas implémentés.

Résumé

Nous n'avons pas été confrontés à la tâche d'intégrer le module logiciel dans le logiciel d'origine,
par conséquent, le matériau décrit dans cet article ne prétend pas être une solution complète.
Nous espérons que les informations présentées ici seront utiles à une certaine catégorie de lecteurs, et au mieux de nos capacités et de la disponibilité de temps libre, nous essaierons de répondre à vos questions.

Merci de votre intérêt!

Les ressources

1. PDF - Lecteur flash intégré mDOC H3 (EFD) avec logiciel de gestion du flash TrueFFS intégré
2. PDF - Programmation des mémoires flash mDOC H3 à l'aide de programmeurs de périphériques Dataman
3. PDF - Software_Utilities_TrueFFS_7.1
4. Logiciel de contrôle de Dataman - PG4UW
5. Implémentation du pilote mDOC H3 pour Linux (les performances n'ont pas été testées)
6. Fichiers source du programmeur hôte (Visual Studio 2017).
7. Fichiers source du module logiciel (IAR Embedded Workbench for ARM v8.30.1).
8. Fichiers source pour FPGA XILINX XC2S50E (XILINX ISE 10.1).