Creating a software module for the programmer XELTEK SuperPro 6100

Foreword

In the previous article , the anti-cloning mechanism of the XELTEK SuperPro 6100 programmer adapters was considered.

This article will describe the creation of a proprietary software module for this programmer, which, by a certain modification of the code, can be adapted to work with any other types of chips - currently not supported or, as in our case, declared only formally.

Prehistory

Once again, we had a task, which at first glance was solved quite simply - it took to make a copy of one specialized flash memory chip - mDOC H3 SDED5-512M.
')
This chip has been developed more than ten years ago. Here is a pdf (1) with its description. Below is a short excerpt from the Russian-language announcement:

... msystems has prepared an mDOC family suitable for use as solid-state drives ...
The TrueFFS firmware, which is entrusted with the management tasks of the mDOC H3 flash memory, runs its own module controller, which turns it into a complete, self-contained unit that is easily added to a variety of handheld devices. ...

In the list of supported by the programmer SuperPro 6100 such a chip was listed and for her even found the appropriate adapter DX5057. But after assembling the entire designer and selecting this chip, the program displayed the following picture with the mysterious item “DimageMain”, the description of which was not found either in the documentation or on the developer’s website.


Having tried to perform the operation “DimageMain” without a chip in the adapter, a warning was received about its absence and after confirming this fact, the program displayed the following information:


Judging by the inscription "mDOC H3 Write Image", "Image" is an image that can be written to a chip using this programmer. But how to read this image from an already recorded chip, how to erase it, etc.?

A little later, on the Internet, there was a file (2) from the company “Dataman”, in which the structure of the above image is partially given and the software for its creation is mentioned.
Thus, further efforts were directed to the search for utilities from M-Systems, described in the document Software Utilities for TrueFFS 7.1 (3) .

The request to the technical support of the former M-Systems, now SanDisk, did not give any result - there was simply no answer.

On the Internet, it was possible to find only old utilities that do not support versions of the H3 chips. The full SDK from SanDisk also could not be found, only its "fragments" (5) in terms of implementing a driver for Linux.

As the accumulated information was studied, the following line attracted attention in the file from Dataman: “Image files can be created with the SanDisk Docshell utility or PG4UW”.

SanDisk Docshell utilities didn’t detect themselves in any way, so I had to figure out how PG4UW (4) works with this chip. They did not embed the entire SDK from SanDisk into their software, but created a plugin with the exported methods necessary for running TrueFFS utilities, which are then called from their program.
We will go the same way.

Creating your own software module

This disclaimer is based on the fact that the author is not responsible for any use you make of the materials in this article.
In other words - only you yourself will be responsible for your actions, to which you may be motivated to become familiar with this material.

Let's agree, as in the previous article, to call the programmer programmer from SuperPro 6100 simply “software”, and the computer on which this program works is “host”. Now we have another program that works in the programmer itself. We will call it “software module”.

The Software Utilities for TrueFFS 7.1 manual (3) describes the functions implemented by the DOCSHELL utilities, which are divided into the following four categories:

• DFORMAT is a utility for formatting an mDOC device.
• DINFO - utilities for obtaining various information about mDOC device and sections existing on it.
• DIMAGE - utilities for reading, writing and comparing the image of an mDOC device.
• SPLITIMAGE - utilities for splitting the image of an mDOC device into parts.

Utilities DOCSHELL intended for the command line, so the interface to communicate with the plugin "DOCSHELL.dll" was implemented using the same mechanism of text commands.
Before you start communicating with the “DOCSHELL.dll”, you must call each of the exported methods and pass in them pointers to the functions implemented in their software for physical exchange with the mDOC chip. These are writing and reading (in several modifications), as well as methods for making text messages about the progress of current operations and methods for working with image files.

One of the exported “mainEntry” methods as input argument
accepts ASCIIZ-string - the command described in the “Software Utilities for TrueFFS 7.1” manual (3) .

The parser inside the “DOCSHELL.dll” processes the received command and, depending on the command itself and its arguments, calls one or another method from the main software of the programmer using the pointer received during the initial initialization.

We decided to write software for the programmer. This approach, on the one hand, relieved us of “digging” in the original files to comply with agreements on the exchange of information between the host and the programmer, and on the other, greatly simplified the debugging process, which in the case of integration of the module into the original software made it impossible in some aspects or extremely difficult.

Own user interface for the programmer was written in C # in Visual Studio 2017. The sources (6) are attached.

In the first place, of course, there was a functional, so there was no question of liking the appearance, as well as the text of the source itself. Therefore, the minimalist "design" of the program is as follows.


At the top of the main (and only) window is a menu, for the buttons of which you can assign arbitrary functions. The menu item “XILINX” will be described below.

Below are two windows. The upper part displays messages sent from the program to the DOCSHELL.dll plugin and received from it.

In the lower window, you can type the commands you need and execute them by double clicking in the corresponding line.

When the program starts, some commands will be displayed in it.

If suddenly you get to work with a real microcircuit - be careful, because no warning that you may lose all data during formatting, etc. The program is not implemented.

The file “DOCSHELL.dll” is found in the directory with the installed program PG4UW (4) from “Dataman” (it is also possible from “Elnec”).

To be able to use a third-party DLL in your program, you need a header file with a description of the exported methods and their arguments. For his absence, I had to recover this information on my own. Methods of such a restoration are beyond the scope of this article, so the arguments of the exported methods can be found in the attached source code.

With the user interface in part of its interaction with the plugin, the case has somewhat cleared up. Now you can go to the implementation of communication with the microcircuit at the physical level in order to be able to execute read / write commands from / to mDOC received from the plugin.

The program module for the programmer was written in C in the IDE "IAR Embedded Workbench for ARM". Sources (7) are attached.

It was debugged using the JTAG J-Link debugger, which is connected to the programmer via a JTAG connector mounted on the side panel of the case and connected to the motherboard with a flat cable.

JTAG debugger J-Link v9 was purchased on Aliexpress. The drivers installed with IAR Embedded Workbench for ARM work fine with it and even the update of the native firmware from SEGGER was successful.


Structurally, the programmer is made in the form of eight boards, one above the other and connected together with connectors.


Adjustable DC-DC converters are placed on the lowest board to form several voltages necessary for operation with various memory chips.
Above it is the motherboard, on which are located the ARM microcontroller ATMEL AT91SAM9G20, SDRAM, SPI FLASH with firmware, the ID chip AE801 with the model of programmer and its serial number, the USB chip of the controller ISP1582, the digital-to-analog converter TLC7226 for controlling the DC-DC converters, a number of other microcircuits and external connectors for connecting the power supply and USB cable for connecting to the host.

The third bottom board houses the XILINX XC2S50E chip, which controls the legs of the chip on the adapter connected to the programmer during read / write procedures, etc.
On the other five boards, there are serially loaded registers and assemblies connected to their outputs with transistor switches, through which you can feed shaped DC-DC voltage converters to one or another chip in an adapter,
including the "land". Since the registers that control the transistor keys are sequential loading, and the number of controllable legs in the adapter can reach 144, it takes considerable time to load all the key blocks. Therefore, using transistor switches, only static levels are fed to the microcircuit: ground, power, etc. And using XILINX - dynamic: addresses, data, CS, OE, RD, WR, etc.

To advance further, it was necessary, at a minimum, to have a tool for creating firmware for the XILINX XC2S50E microcircuit and a circuit diagram, if not of the entire programmer, then at least its part of the CPU — the FPGA adapter of the socket.

As for the IDE for XILINX Spartan-IIE, I had to use the old version of ISE 10.1, because all subsequent IDEs do not support the Spartan-II FPGA model.

With the concept of the situation was more difficult. In order to identify the connections we are interested in, we had to remove the U4 and XILINX U12 processors from the motherboards in order to gain access to the pads under their BGA packages, since not all of them go to the other side.
The mechanism of communication between the host and the programmer is carried out via USB through several endpoints. The host always acts as a lead. Through one of the endpoints, the host transmits a command to the programmer and through it receives a confirmation,
through the other exchange data between themselves.

Parsing commands from the host in a software module is done in the USB_ReceiveBuf_EP1RX_Parse () method.

The command packet is described by the CMD_PROG structure and consists of several fields. If the Cmd field contains 1, then this is the command for working with the microcircuit and the ProgProcNum field in this case is the index in the _progProcedures array of PROG_PROC structures, in one of the fields of which the pointer to the command being executed is stored.

In the directory with the installed program "SUPERPRO 6100N" is the subdirectory "\ lib". XILINX firmware files for all types of microcircuits supported by the programmer are stored in it with the extension "* .bin". Among them there are two universal firmware for checking the contact of the legs of the chip with the contacts sockets in the adapter.

These are the “GENERAL ~ .BIN” with the inner pull-up of all XILINX pull-up legs and the GENERAL_.BIN with the inner pull-down pull-up.

Checking the contact of the legs of the chip is carried out in the SOCKET_CkeckInsertIC () method of the program module as follows.

First, the “GENERAL_.BIN” firmware is loaded into XILINX and with its help all the FPGA legs connected to the socket are tuned to the output and logical “1” are fed to them. Then, each FPGA leg is alternately tuned to the input, a logical level is read from it, and then “1” is output to this leg again.

If the chip foot has electrical contact with the corresponding foot sockets, then it should read "1" (through the internal protective diodes of the chip from all other legs). And if there is no contact due to the fact that all the FPGA pins are pulled into the “ground” from this input, “0” will be read. After that, the array of logical levels read in this way is sent to the host and processed there. Then the execution of the specified operation proceeds, or a message about the non-contact of the corresponding legs of the chip in the socket is displayed.
After successfully passing this test, the host sends to the programmer the XILINX firmware corresponding to the chip installed in the adapter.

Compiling a program for FPGA in ISE 10.1 (sequential execution of synthesis procedures (Synthesize), implementation of design (Implement Design) and generation of files for programming (Generate Programming File)) creates in the project directory a binary configuration file "xeltek.bin" of 78756 bytes in size. To do this, two options must be set in the properties of the Generate Programming File process in the Processes window in the General Options category: Create Bit File and Create Bibary Configuration File.

It is not known for what reasons, but programmers from XELTEK decided to modify the files obtained in this way by mirroring all the bits in each byte.

If for some reason you need to “mirror” your own file in this way, or to “mirror” the file from the "\ lib" directory back to normal, in the software in the "XILINX" menu there is a “Bitstream Converter” item (at the end of the resulting file is underlined).

To work with the SDED5 chip on the physical level, the following four methods are implemented in the software module:

- PROGPROC_FLWRITE_IO_WORD () - write a word (16 bits) at a given address
- PROGPROC_FLREAD_IO_WORD () - read words (16 bits) at a given address
- PROGPROC_hal_blk_write_nor () - write one or several sectors (512 bytes) at a given address
- PROGPROC_hal_blk_read_nor () - reading one or several sectors (at 512 bytes) at a given address

To interact with the FPGA XILINX, we identified four registers in our firmware (the I / O ports described in the common.h file of the ARM sources).

- _IC_ADDR (0x30000010)
- _IC_DATA (0x30000012)
- _IC_CTRL (0x30000014) // Out: 0 - WE, 1 - 0E, 2 - CE, 3 - RSTIN; In: 0 - BUSY
- _IC_ENABLE (0x30000016) // In: 7 - Work enable (0 - active, 1 - all the legs on the socket in Z)

_IC_ADDR and _IC_DATA are the 16-bit address and data registers for the programmable chip SDED5;
_IC_CTRL - 8-bit control register, through which the WE, OE, CE and RSTIN signals are set and the BUSY signal is read from SDED5.

The original software modules for communication with FPGA use addresses from 0x30000000 to 0x3000000E. The CPLD with the XELTEK inscription is set as the address decoder in the programmer, and since its firmware is not known to us, we, just in case, used addresses with 0x30000010 to reduce the likelihood of unexpected consequences from the manifestation of someone else's behavior when using "standard" addresses.

After loading the FPGA of its firmware, all the FPGA outputs connected to the legs of the chip in the socket are in the Z state and to start working with it you need to enable the resolution by writing zero to the seventh bit of the _IC_ENABLE register.

The algorithm of the entire system may look as follows.

1. After starting the software on the host, it checks if there is a connection to the programmer via USB and displays the corresponding message in the status line at the bottom of the main window
   (the programmer can be connected after the start of the program).
2. The user selects the type of chip with which he intends to work.
3. In the database (in the simplest case, just in the file) there is a match between the selected chip and the type of adapter required, and a request is sent to the programmer for the type of adapter installed in it.
4. The programmer asks the adapter for its type and sends this information back to the host, where this information is compared with that found in the database and if the adapter types match, the work continues.
5. For each type of chip selected, a corresponding menu should be displayed in the software with the commands available for that chip (read, write, check for purity, compare, etc.).
6. When you select any menu item for working with a chip, the corresponding command is sent to the programmer, after which the programmer first checks whether there is an electrical contact between the sockets and the legs of the chip, and then, if successful, executes this command.

In the source code attached to the article to simplify the task, the items from the second to the fifth inclusive are not implemented.

Total

We were not faced with the task of integrating the software module into the original software,
therefore, the material described in this article does not claim to be complete.
We hope that the information presented here will be useful for a certain category of readers, and we will try to answer your questions as far as possible and free time.

Thank you for your interest!

Resources

one. PDF - mDOC H3 Embedded Flash Drive (EFD) featuring Embedded TrueFFS Flash Management Software
2 PDF - Programming mDOC H3 Flash Memories Using Dataman Device Programmers
3 PDF - Software_Utilities_TrueFFS_7.1
four. Dataman Control Software - PG4UW
five. Implementation of the mDOC H3 driver for Linux (performance not tested)
6 Source files for the host programmer (Visual Studio 2017).
7 Source files of the program module (IAR Embedded Workbench for ARM v8.30.1).
eight. Source files for FPGA XILINX XC2S50E (XILINX ISE 10.1).