Creating a software module for the programmer XELTEK SuperPro 6100
In the previous article , the anti-cloning mechanism of the XELTEK SuperPro 6100 programmer adapters was discussed.
This article will describe the creation of a proprietary software module for this programmer, which, by means of a specific code modification, can be adapted to work with any other type of chipset - currently not supported or, as in our case, declared only formally.
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
embedded TrueFFS software, which is responsible for managing flash memory mDOC H3, performs its own controller of the module, which turns it into A complete, stand-alone unit, easily added to a variety of handheld devices.…
In the list supported by the SuperPro 6100 programmer, such a chip was listed and for it there was even a corresponding adapter DX5057. But after assembling the entire designer and selecting this chip, the program displayed the following picture with the mysterious item “DimageMain”, the descriptions of which were 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 the H3 chip versions. 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 “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
takes an ASCIIZ string as an input argument — 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 obtained 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 the module integration 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 there 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, it will display some commands.
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 (you can also 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, this information had to be restored independently. Methods of such a restoration are beyond the scope of this article, therefore 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 become somewhat clearer. Now you can proceed 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 that are installed with IAR Embedded Workbench for ARM work great with it, and even the SEGGER native firmware update 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 required for operation with various memory chips.
Above it is the motherboard, on which are located ARM microcontroller ATMEL AT91SAM9G20, SDRAM, SPI FLASH with firmware, ID chip AE801 with a programmer model and its serial number, USB chip of the ISP1582 controller, digital-to-analog converter TLC7226 for controlling DC-DC converters, a number of other chips and external connectors for connecting the power supply and USB cable to connect 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 chip-shaped DC-DC voltage converters
, including ground, formed on these or other microcircuit legs in the adapter . 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.
In order to advance further, it was necessary to have, at a minimum, a means of 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, since all subsequent IDEs do not support the Spartan-II FPGA model.
With the concept of the situation was more difficult. To identify the connections we are interested in, we had to remove the U4 and XILINX U12 processor 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.
through the other they exchange data with each other.
Parsing commands from the host in the program 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 to check the contact of the legs of the chip with the contacts sockets in the adapter.
This is a “GENERAL ~ .BIN” with an internal pull-up pull of all XILINX legs and a GENERAL_.BIN with an internal pull-down pull.
Check the contact of the legs of the chip is carried out in the method SOCKET_CkeckInsertIC () 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 microchip's foot has electrical contact with the corresponding foot sockets, then it should read “1” (through the internal protective diodes of the microcircuit from all other legs). And if there is no contact due to the fact that all FPGA pins are pulled into the “ground” from this input, “0” will be read. After that, an 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 microcircuit in the socket is displayed.
After successful completion of this test, the host sends to the programmer the firmware for XILINX 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 “mirror” the file from the "\ lib" directory back to the normal view, in the software in the "XILINX" menu there is a "Bitstream Converter" item (at the end of the name The resulting file is underlined).
To work with the chip SDED5 at the physical layer in a software module provides the following four methods:
- PROGPROC_FLWRITE_IO_WORD () - Record the word (16 bits) at the specified address
- PROGPROC_FLREAD_IO_WORD () - Read a word (16 bits) at the specified address
- PROGPROC_hal_blk_write_nor () - Recording one or several sectors (512 bytes) at a given address
- PROGPROC_hal_blk_read_nor () - read one or several sectors (512 bytes) at a specified address
To interact with the XILINX FPGA, we defined 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 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 the 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 downloading the FPGA to 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.
- After the start of the software on the host, it checks whether 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).
- The user selects the type of chip with which he intends to work.
- In the database (in the simplest case - just in the file), the selected chip corresponds to the type of adapter required and a request is sent to the programmer for the type of adapter installed in it.
- 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.
- For each type of chip selected in the software, the corresponding menu should be displayed with the commands available for this chip (read, write, check for purity, comparison, etc.).
- 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 for the electrical contact of the sockets with the legs of the chip, and then, if successful, executes this command.
In the source code attached to the article to simplify the task, paragraphs two through five are not implemented.
We were not faced with the task of integrating the software module into the original software,
so 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!
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
4.Dataman Control Software - PG4UW
5.Implementation of the mDOC H3 driver for Linux (performance not tested)
6.Source files for the host programmer (Visual Studio 2017).
7Source files of the program module (IAR Embedded Workbench for ARM v8.30.1).
eight.The source files for the XILINX XC2S50E FPGA (XILINX ISE 10.1).