Crear un módulo de software para el programador XELTEK SuperPro 6100

Prólogo

En un artículo anterior, se consideró el mecanismo de protección del programador XELTEK SuperPro 6100 contra la clonación.

Este artículo describirá la creación de su propio módulo de software para este programador, que, mediante una cierta modificación del código, se puede adaptar para trabajar con cualquier otro tipo de microcircuitos, actualmente no es compatible o, como en nuestro caso, se declara solo formalmente.

Antecedentes

Una vez más, tuvimos una tarea que a simple vista se resolvió de manera bastante simple: era necesario hacer una copia de un chip de memoria flash especializado: mDOC H3 SDED5-512M.

Este chip fue desarrollado hace más de diez años. Aquí está el pdf (1) con su descripción. A continuación se muestra un breve extracto del anuncio en ruso:

... msystems ha preparado la familia mDOC para su uso como unidades de estado sólido ...
El software TrueFFS incorporado, que tiene la tarea de administrar la memoria flash mDOC H3, ejecuta su propio módulo controlador, que lo convierte en una unidad completa e independiente, que se agrega fácilmente a una variedad de dispositivos de mano ...

En la lista de SuperPro 6100 compatible con el programador, se incluyó dicho chip e incluso se encontró el adaptador DX5057 correspondiente. Pero después de reunir a todo el diseñador y elegir este chip, el programa mostró la siguiente imagen con el misterioso elemento "DimageMain", cuya descripción no se encontró ni en la documentación ni en el sitio web del desarrollador.


Después de intentar realizar la operación "DimageMain" sin un chip en el adaptador, se recibió una advertencia sobre su ausencia, y después de confirmar este hecho, el programa mostró la siguiente información:


A juzgar por la inscripción "mDOC H3 Write Image", "Imagen" es una imagen que se puede escribir en un chip utilizando este programador. Pero, ¿cómo leer esta imagen de un microcircuito ya grabado, cómo borrarla, etc.?

Un poco más tarde en Internet encontré un archivo (2) de la compañía Dataman, que muestra parcialmente la estructura de la imagen anterior y menciona el software para su creación.
Por lo tanto, los esfuerzos adicionales se dirigieron a la búsqueda de utilidades de M-Systems descritas en el documento Software Utilities for TrueFFS 7.1 (3) .

La solicitud de soporte técnico de los antiguos "M-Systems", ahora "SanDisk", no dio resultado, simplemente no hubo respuesta.

En Internet, solo era posible encontrar utilidades antiguas que no admitían la versión de chips H3. Tampoco se encontró el SDK completo de SanDisk, solo sus "fragmentos" (5) en términos de implementación de un controlador para Linux.

A medida que estudiamos la información acumulada, la siguiente línea llamó la atención del archivo Dataman: "Los archivos de imagen se pueden crear con la utilidad SanDisk Docshell o PG4UW".

Las utilidades de SanDisk Docshell no se encontraron de ninguna manera, así que tuve que descubrir cómo funciona PG4UW (4) con este chip. No integraron todo el SDK de SanDisk en su software, sino que crearon un complemento con los métodos exportados necesarios para que funcionen las utilidades TrueFFS, que luego se llaman desde su programa.
Nosotros iremos por el mismo camino.

Creando tu propio módulo de software

Aquí hay un descargo de responsabilidad, a saber, que el autor no tiene ninguna responsabilidad por el uso que usted haga de los materiales de este artículo.
En otras palabras, solo usted mismo será responsable de sus acciones, lo que puede alentarlo a familiarizarse con este material.

Acordamos, como en el artículo anterior, llamar al programador programador de SuperPro 6100 simplemente "software", y la computadora en la que funciona este programa es "host". Ahora tenemos otro programa que funciona en el programador mismo. Lo llamaremos el "módulo de software".

El manual Software Utilities for TrueFFS 7.1 (3) describe las funciones implementadas por las utilidades DOCSHELL, que se dividen en las siguientes cuatro categorías:

• DFORMAT: utilidades para formatear un dispositivo mDOC.
• DINFO: utilidades para obtener una variedad de información sobre el dispositivo mDOC y las secciones existentes en él.
• DIMAGE: utilidades para leer, escribir y comparar el dispositivo mDOC de imagen.
• SPLITIMAGE: utilidades para dividir la imagen del dispositivo mDOC en partes.

Las utilidades DOCSHELL estaban destinadas a la línea de comando, por lo tanto, la interfaz para comunicarse con el complemento DOCSHELL.dll se implementó utilizando el mismo mecanismo de comando de texto.
Antes de comenzar la comunicación con "DOCSHELL.dll", es necesario llamar a cada uno de los métodos exportados y pasarles punteros a las funciones implementadas en el software para el intercambio físico con el chip mDOC. Estos son escritura y lectura (en varias modificaciones), así como métodos para recibir mensajes de texto sobre el progreso de las operaciones actuales y métodos para trabajar con archivos de imagen.

Uno de los métodos mainEntry exportados como argumento de entrada
acepta una cadena ASCIIZ: el comando descrito en el Manual de utilidades de software para TrueFFS 7.1 (3) .

El analizador dentro de "DOCSHELL.dll" procesa el comando recibido y, dependiendo del comando y sus argumentos, llama a uno u otro método desde el software del programador principal utilizando el puntero recibido durante la inicialización inicial.

Software para el programador, decidimos escribir el suyo. Este enfoque, por un lado, nos salvó de "cavar" en los archivos originales para cumplir con los acuerdos sobre el intercambio de información entre el host y el programador, y por otro lado, facilitó enormemente el proceso de depuración, que, si el módulo se integraba en el software original, lo hacía imposible en algunos aspectos o extremadamente difícil.

La interfaz de usuario nativa para el programador se escribió en C # en Visual Studio 2017. Se incluyen las fuentes (6) .

Por supuesto, funcional era en primer lugar, por lo que no se trataba de ningún ajuste de la apariencia, así como del texto del código fuente en sí. Por lo tanto, el "diseño" minimalista del programa es el siguiente.


En la parte superior de la ventana principal (y única) hay un menú para los botones a los que puede asignar funciones arbitrarias. El elemento del menú "XILINX" se describirá más adelante.

Debajo hay dos ventanas. La parte superior muestra los mensajes enviados desde el programa al complemento "DOCSHELL.dll" y recibidos de él.

En la ventana inferior, puede escribir los comandos que necesita y hacer doble clic en ellos en la línea correspondiente.

Cuando se inicia el programa, se mostrarán algunos comandos en él.

Si de repente puedes trabajar con un chip real, ten cuidado, porque sin advertencias de que puede perder todos los datos al formatear, etc. El programa no está implementado.

El archivo "DOCSHELL.dll" se encuentra en el directorio con el programa PG4UW (4) instalado de "Dataman" (es posible desde "Elnec").

Para poder utilizar una DLL de terceros en su programa, necesita un archivo de encabezado con una descripción de los métodos exportados y sus argumentos. Debido a su ausencia, tuve que recuperar esta información yo mismo. Los métodos para dicha recuperación están más allá del alcance de este artículo, por lo que los argumentos de los métodos exportados se pueden encontrar en las fuentes adjuntas.

Con la interfaz de usuario en términos de su interacción con el complemento, el asunto se ha vuelto algo más claro. Ahora puede proceder a la implementación de la comunicación con el microcircuito a nivel físico para poder ejecutar los comandos de lectura / escritura de / a mDOC recibidos del complemento.

El módulo de programa para el programador fue escrito en lenguaje C en el IDE "IAR Embedded Workbench for ARM". Se adjuntan las fuentes (7) .

Su depuración se realizó utilizando el depurador JTAG J-Link, conectado al programador a través de un conector JTAG montado en el lateral de la carcasa y conectado a la placa base por un cable plano.

El depurador JTAG J-Link v9 se compró en Aliexpress. Los controladores instalados con el "IAR Embedded Workbench for ARM" funcionan de maravilla e incluso la actualización del firmware nativo de SEGGER fue exitosa.


Estructuralmente, el programador está hecho en forma de ocho tableros ubicados uno encima del otro y conectados entre sí mediante conectores.


Los convertidores DC-DC ajustables se encuentran en la placa más baja para generar varios voltajes necesarios para trabajar con varios microcircuitos de memoria.
Arriba hay una placa base en la cual el microcontrolador ARM ATMEL AT91SAM9G20, SDRAM, SPI FLASH con firmware, chip de identificación AE801 con modelo de programador y número de serie, chip USB ISP1582, convertidor digital a analógico TLC7226 para gestión de voltaje de convertidores CC-CC, una serie de otros chips y conectores externos para conectar una fuente de alimentación y un cable USB para conectarse al host.

En la tercera placa inferior está el chip XILINX XC2S50E, que controla las patas del chip en el adaptador conectado al programador durante los procedimientos de lectura / escritura, etc.
En las otras cinco placas hay registros y conjuntos cargados secuencialmente conectados a sus salidas con teclas de transistor, a través de las cuales es posible aplicar microcircuitos a uno u otro tramo del chip formado por convertidores de voltaje CC-CC,
incluyendo la "tierra". Dado que los registros que controlan las teclas del transistor se cargan secuencialmente y el número de patas controladas en el adaptador puede llegar a 144, se tarda un tiempo considerable en cargar todos los bloques de teclas. Por lo tanto, con la ayuda de interruptores de transistor, solo se alimentan niveles estáticos al microcircuito: tierra, energía, etc. Y con XILINX: dinámico: direcciones, datos, CS, OE, RD, WR, etc.

Para avanzar aún más, era necesario, como mínimo, tener un medio para crear firmware para el microcircuito XILINX XC2S50E y un diagrama de circuito, si no de todo el programador, al menos parte de él CPU - FPGA - adaptador - zócalo.

En cuanto al IDE para XILINX Spartan-IIE, tuve que usar la versión anterior de ISE 10.1, porque Todos los IDE posteriores no son compatibles con el modelo FPGA Spartan-II.

La situación con el diagrama del circuito resultó ser más complicada. Para identificar los compuestos que nos interesan, tuvimos que "quitar" el procesador U4 y XILINX U12 de las placas para obtener acceso a las almohadillas debajo de sus estuches BGA, porque No todos tienen un interruptor en el reverso.
El host se comunica con el programador a través de USB a través de varios puntos finales (puntos finales). El anfitrión siempre actúa como anfitrión. A través de uno de los puntos finales, el host envía un comando al programador y a través de él recibe confirmación,
a través de otro intercambian datos entre sí.

Los comandos de análisis desde el host en el módulo del programa se realizan en el método USB_ReceiveBuf_EP1RX_Parse ().

El paquete de comandos está descrito por la estructura CMD_PROG y consta de varios campos. Si el campo Cmd contiene 1, entonces este es un comando para trabajar con el microcircuito y el campo ProgProcNum en este caso es el índice en la matriz _progProcedures de estructuras PROG_PROC, en uno de los campos donde se almacena un puntero al comando a ejecutar.

En el directorio con el programa instalado "SUPERPRO 6100N" hay un subdirectorio "\ lib". Con la extensión "* .bin", se almacenan los archivos de firmware XILINX para todos los tipos de chips admitidos por el programador. Entre ellos hay dos firmware universales para verificar el contacto de las patas del microcircuito con los contactos de los enchufes en el adaptador.

Esto es "GENERAL ~ .BIN" con un pull-up interno para todas las patas pull-up de XILINX y "GENERAL_.BIN" con un pull-pull interno.

La verificación del contacto de las patas del chip se realiza en el método SOCKET_CkeckInsertIC () del módulo de software de la siguiente manera.

Primero, el firmware "GENERAL_.BIN" se carga en XILINX y, con su ayuda, todas las patas FPGA conectadas al zócalo se configuran para la salida y se les proporciona "1" lógico. Luego, a su vez, cada tramo FPGA se reconfigura a la entrada, se lee un nivel lógico y luego se devuelve "1" a este tramo.

Si la pata del microcircuito tiene contacto eléctrico con la pata del zócalo correspondiente, entonces debe leerse "1" (a través de los diodos protectores internos del microcircuito de todas las demás patas). Y en ausencia de contacto, debido al hecho de que todos los pines FPGA se insertan en el suelo, se leerá "0" desde esta entrada. Después de eso, una matriz de niveles lógicos leídos de esta manera se envía al host y se procesa allí. A continuación, la ejecución de la operación especificada continúa o se muestra un mensaje sobre el no contacto de las patas correspondientes del microcircuito en el zócalo.
Después de pasar con éxito esta prueba, el host envía al programador el firmware para XILINX correspondiente al chip instalado en el adaptador.

Al compilar un programa para FPGA en ISE 10.1 (ejecución secuencial de procedimientos de síntesis (Sintetizar), implementación de un diseño (Implementar diseño) y generación de archivos de programación (Generar archivo de programación)) se crea un archivo de configuración binario "xeltek.bin" de 78756 bytes en el directorio del proyecto. Para esto, en las propiedades del proceso "Generar archivo de programación" en la ventana "Procesos" en la categoría "Opciones generales", se deben establecer dos opciones: "Crear archivo de bits" y "Crear archivo de configuración de biblioteca".

No se sabe por qué razones, pero los programadores de XELTEK decidieron modificar los archivos así obtenidos al reflejar todos los bits en cada byte.

Si por alguna razón necesita "reflejar" su propio archivo de esta manera, o "reflejar" el archivo del directorio "\ lib" de nuevo a la vista normal, en el software en el menú "XILINX" hay para este propósito el elemento "Bitstream Converter" (al final del nombre el archivo resultante está subrayado).

Para trabajar con el chip SDED5 a nivel físico, se implementan los siguientes cuatro métodos en el módulo de software:

- PROGPROC_FLWRITE_IO_WORD () - graba una palabra (16 bits) en la dirección especificada
- PROGPROC_FLREAD_IO_WORD () - lee la palabra (16 bits) en la dirección especificada
- PROGPROC_hal_blk_write_nor () - escribe uno o más sectores (512 bytes cada uno) en la dirección especificada
- PROGPROC_hal_blk_read_nor () - lee uno o más sectores (512 bytes cada uno) en la dirección especificada

Para interactuar con el FPGA XILINX en nuestro firmware, identificamos cuatro registros (puertos de E / S, descritos en el archivo common.h para fuentes ARM).

- _IC_ADDR (0x30000010)
- _IC_DATA (0x30000012)
- _IC_CTRL (0x30000014) // Fuera: 0 - WE, 1 - 0E, 2 - CE, 3 - RSTIN; En: 0 - OCUPADO
- _IC_ENABLE (0x30000016) // En: 7 - Permiso de trabajo (0 - activo, 1 - todas las patas en el zócalo en Z)

_IC_ADDR y _IC_DATA son registros de datos y direcciones de 16 bits para el chip programable SDED5;
_IC_CTRL - Registro de control de 8 bits a través del cual se establecen las señales WE, OE, CE y RSTIN y la señal BUSY se lee desde SDED5.

Los módulos de software originales utilizan direcciones de 0x30000000 a 0x3000000E para comunicarse con FPGA. CPLD con la inscripción XELTEK se instala como un decodificador de direcciones en el programador, y como no conocemos su firmware, utilizamos direcciones de 0x30000010 por si acaso para reducir la probabilidad de consecuencias inesperadas de manifestar la lógica de comportamiento de otra persona cuando se usan direcciones "estándar".

Después de cargar su firmware en el FPGA, todas las salidas FPGA conectadas a las patas del microcircuito en el zócalo están en estado Z y para comenzar a trabajar con él, debe habilitar la resolución escribiendo cero en el séptimo bit del registro _IC_ENABLE.

El algoritmo de todo el sistema puede verse de la siguiente manera.

1. Después de iniciar el software en el host, comprueba si hay una conexión con el programador a través de USB y muestra el mensaje correspondiente en la barra de estado en la parte inferior de la ventana principal
   (el programador se puede conectar después del inicio del programa).
2. El usuario selecciona el tipo de chip con el que tiene la intención de trabajar.
3. En la base de datos (en el caso más simple, solo en el archivo), el microcircuito seleccionado coincide con el tipo de adaptador requerido y se envía una solicitud al programador para el tipo de adaptador instalado en él.
4. El programador pregunta al adaptador por su tipo y envía esta información al host, donde se compara esta información con la que se encuentra en la base de datos, y si los tipos de adaptador coinciden, el trabajo continúa.
5. Para cada tipo de microcircuito seleccionado en el software, se debe mostrar un menú correspondiente con los comandos disponibles para ese microcircuito (leer, escribir, verificar la limpieza, comparación, etc.).
6. Cuando selecciona un elemento de menú para trabajar con el microcircuito, el comando correspondiente se envía al programador, después de lo cual el programador primero verifica el contacto eléctrico de los contactos de los enchufes con las patas del microcircuito y luego, si tiene éxito, ejecuta este comando.

En los códigos fuente adjuntos al artículo, para simplificar la tarea, no se implementan los puntos del segundo al quinto inclusive.

Resumen

No nos enfrentamos a la tarea de integrar el módulo de software en el software original,
por lo tanto, el material descrito en este artículo no pretende ser una solución completa.
Esperamos que la información presentada aquí sea útil para una determinada categoría de lectores y, en la medida de nuestras posibilidades y la disponibilidad de tiempo libre, intentaremos responder a sus preguntas.

Gracias por su interes!

Recursos

1) PDF - Unidad flash incorporada mDOC H3 (EFD) con software de gestión de flash TrueFFS incorporado
2) PDF - Programación de memorias Flash mDOC H3 utilizando programadores de dispositivos Dataman
3) PDF - Software_Utilities_TrueFFS_7.1
4) Software de control Dataman - PG4UW
5) Implementación del controlador mDOC H3 para Linux (no se probó el rendimiento)
6) Archivos de origen del programador host (Visual Studio 2017).
7) Archivos de origen del módulo de software (IAR Embedded Workbench para ARM v8.30.1).
8) Archivos de origen para FPGA XILINX XC2S50E (XILINX ISE 10.1).