Criando um módulo de software para o programador XELTEK SuperPro 6100

Prefácio

Em um artigo anterior, foi considerado o mecanismo de proteção do programador XELTEK SuperPro 6100 contra a clonagem.

Este artigo descreverá a criação de seu próprio módulo de software para esse programador, que, com uma certa modificação do código, pode ser adaptado para funcionar com qualquer outro tipo de microcircuito - atualmente não suportado ou, como no nosso caso, declarado formalmente.

Antecedentes

Mais uma vez, tivemos uma tarefa que, à primeira vista, foi resolvida com bastante simplicidade - era necessário fazer uma cópia de um chip de memória flash especializado - mDOC H3 SDED5-512M.

Este chip foi desenvolvido há mais de dez anos. Aqui está o pdf (1) com sua descrição. Abaixo está um pequeno trecho do anúncio em russo:

... a msystems preparou a família mDOC para uso como unidades de estado sólido ...
O software TrueFFS interno, encarregado de gerenciar a memória flash mDOC H3, executa seu próprio módulo controlador, que o transforma em uma unidade completa e independente, facilmente adicionada a uma variedade de dispositivos portáteis.

Na lista do SuperPro 6100 suportado pelo programador, esse chip foi listado e até encontrou o adaptador DX5057 correspondente. Porém, após montar todo o designer e escolher esse chip, o programa mostrou a seguinte imagem com o item misterioso “DimageMain”, cuja descrição não foi encontrada na documentação ou no site do desenvolvedor.


Depois de tentar executar a operação “DimageMain” sem um chip no adaptador, foi recebido um aviso sobre sua ausência e, após confirmar esse fato, o programa exibiu as seguintes informações:


A julgar pela inscrição “mDOC H3 Write Image”, “Image” é uma imagem que pode ser gravada em um chip usando este programador. Mas como ler esta imagem de um microcircuito já gravado, como apagá-la etc.?

Um pouco mais tarde, na Internet, encontrei um arquivo (2) da empresa Dataman, que mostra parcialmente a estrutura da imagem acima e menciona o software para sua criação.
Assim, esforços adicionais foram direcionados à busca de utilitários da M-Systems descritos no documento Software Utilities for TrueFFS 7.1 (3) .

O pedido de suporte técnico do antigo “M-Systems”, agora “SanDisk”, não deu resultado - simplesmente não houve resposta.

Na Internet, foi possível encontrar apenas utilitários antigos que não suportam a versão dos chips H3. O SDK completo da SanDisk também não foi encontrado, apenas seus "fragmentos" (5) em termos de implementação de um driver para Linux.

Enquanto estudamos as informações acumuladas, a seguinte linha chamou a atenção do arquivo Dataman: "Os arquivos de imagem podem ser criados com o utilitário SanDisk Docshell ou PG4UW".

Os utilitários SanDisk Docshell não se encontravam de forma alguma, então eu tive que descobrir como o PG4UW (4) funciona com esse chip. Eles não incorporaram o SanDisk SDK inteiro em seu software, mas criaram um plug-in com métodos exportados necessários para o funcionamento dos utilitários TrueFFS, que são chamados a partir de seu programa.
Vamos seguir o mesmo caminho.

Criando seu próprio módulo de software

Aqui está uma isenção de responsabilidade, a saber, que o autor não se responsabiliza pelo uso que você fizer dos materiais deste artigo.
Em outras palavras - somente você será responsável por suas ações, o que poderá ser incentivado a se familiarizar com este material.

Concordamos, como no artigo anterior, chamar o programador do SuperPro 6100 simplesmente de "software", e o computador no qual esse programa trabalha é "host". Agora temos outro programa que funciona no próprio programador. Vamos chamá-lo de "módulo de software".

O manual Software Utilities for TrueFFS 7.1 (3) descreve as funções implementadas pelos utilitários DOCSHELL, que se enquadram nas quatro categorias a seguir:

• DFORMAT - utilitários para formatar um dispositivo mDOC.
• DINFO - utilitários para obter uma variedade de informações sobre o dispositivo mDOC e as seções existentes nele.
• DIMAGE - utilitários para leitura, gravação e comparação do dispositivo mDOC de imagem.
• SPLITIMAGE - utilitários para dividir a imagem do dispositivo mDOC em partes.

Os utilitários DOCSHELL foram projetados para a linha de comando; portanto, a interface para comunicação com o plug-in DOCSHELL.dll foi implementada usando o mesmo mecanismo de comando de texto.
Antes de iniciar a comunicação com o "DOCSHELL.dll", é necessário chamar cada um dos métodos exportados e passar neles indicadores para as funções implementadas no software para troca física com o chip mDOC. Eles estão escrevendo e lendo (em várias modificações), bem como métodos para receber mensagens de texto sobre o andamento das operações atuais e métodos para trabalhar com arquivos de imagem.

Um dos métodos mainEntry exportados como argumento de entrada
aceita uma string ASCIIZ - o comando descrito no manual Software Utilities for TrueFFS 7.1 (3) .

O analisador dentro de "DOCSHELL.dll" processa o comando recebido e, dependendo do comando e de seus argumentos, chama um ou outro método do software principal do programador usando o ponteiro recebido durante a inicialização.

Software para o programador, decidimos escrever o seu. Essa abordagem, por um lado, nos salvou de “cavar” nos arquivos originais para cumprir acordos de troca de informações entre o host e o programador, e por outro lado, facilitou bastante o processo de depuração, que, se o módulo foi integrado ao software original, tornou impossível em alguns aspectos ou extremamente difícil.

A interface do usuário nativa do programador foi escrita em C # no Visual Studio 2017. As fontes (6) estão incluídas.

Obviamente, funcional estava em primeiro lugar, portanto não havia questão de alterar a aparência, assim como o texto do código fonte. Portanto, o design minimalista do programa é o seguinte.


Na parte superior da janela principal (e somente), há um menu para os botões aos quais você pode atribuir funções arbitrárias. O item de menu “XILINX” será descrito mais adiante.

Abaixo estão duas janelas. A parte superior exibe as mensagens enviadas do programa para o plug-in "DOCSHELL.dll" e recebidas dele.

Na janela inferior, você pode digitar os comandos necessários e clicar duas vezes neles na linha correspondente.

Quando o programa inicia, alguns comandos serão exibidos nele.

Se você repentinamente começar a trabalhar com um chip real - tenha cuidado, porque nenhum aviso de que você pode perder todos os dados ao formatar, etc. O programa não está implementado.

O arquivo "DOCSHELL.dll" é encontrado no diretório com o programa PG4UW (4) instalado em "Dataman" (é possível em "Elnec").

Para poder usar uma DLL de terceiros em seu programa, você precisa de um arquivo de cabeçalho com uma descrição dos métodos exportados e seus argumentos. Devido à sua ausência, tive que recuperar essas informações pessoalmente. Os métodos para essa recuperação estão além do escopo deste artigo, portanto, os argumentos dos métodos exportados podem ser encontrados nas fontes anexadas.

Com a interface do usuário em termos de interação com o plugin, o assunto se tornou um pouco mais claro. Agora você pode prosseguir com a implementação da comunicação com o microcircuito no nível físico para poder executar os comandos de leitura / gravação de / para o mDOC recebidos do plug-in.

O módulo do programa para o programador foi escrito em linguagem C no IDE "IAR Embedded Workbench for ARM". Fontes (7) estão anexadas.

Sua depuração foi realizada usando o depurador JTAG J-Link, conectado ao programador por um conector JTAG montado na lateral do gabinete e conectado à placa-mãe por um cabo plano.

O depurador JTAG J-Link v9 foi adquirido no Aliexpress. Os drivers instalados com o “IAR Embedded Workbench for ARM” funcionam maravilhosamente com ele, e até mesmo a atualização do firmware nativo da SEGGER foi bem-sucedida.


Estruturalmente, o programador é feito na forma de oito placas localizadas uma acima da outra e conectadas por conectores.


Conversores DC-DC ajustáveis ​​estão localizados na placa mais baixa para gerar várias voltagens necessárias para trabalhar com vários microcircuitos de memória.
Acima dela, há uma placa-mãe na qual o microcontrolador ATMEL AT91SAM9G20 ARM, SDRAM, SPI FLASH com firmware, chip de identificação AE801 com modelo e número de série do programa, chip USB ISP1582, conversor digital-analógico TLC7226 para gerenciamento de tensão de conversores DC-DC, vários outros chips e conectores externos para conectar uma fonte de alimentação e um cabo USB para conectar ao host.

Na terceira placa inferior está o chip XILINX XC2S50E, que controla as pernas do chip no adaptador conectado ao programador durante os procedimentos de leitura / gravação, etc.
Nas outras cinco placas, há registros e conjuntos carregados sequencialmente, conectados às suas saídas com chaves de transistor, através dos quais é possível aplicar microcircuitos a uma ou outra perna do chip formado por conversores de tensão DC-DC,
incluindo a "terra". Como os registros que controlam as chaves do transistor são carregados sequencialmente e o número de pernas controladas no adaptador pode chegar a 144, leva um tempo considerável para carregar todos os blocos de chaves. Portanto, com a ajuda dos comutadores de transistor, apenas níveis estáticos são alimentados ao microcircuito: terra, energia, etc. E com o XILINX - dinâmico: endereços, dados, CS, OE, RD, WR, etc.

Para avançar ainda mais, era necessário, no mínimo, um meio de criar firmware para o microcircuito XILINX XC2S50E e um diagrama de circuito, se não de todo o programador, pelo menos parte do soquete CPU - FPGA - adaptador -.

Quanto ao IDE para XILINX Spartan-IIE, eu tive que usar a versão antiga do ISE 10.1, porque todos os IDEs subsequentes não suportam o modelo FPartan Spartan-II.

A situação com o diagrama do circuito acabou sendo mais complicada. Para identificar os compostos de interesse para nós, tivemos que "remover" o processador U4 e XILINX U12 das placas para obter acesso aos blocos nos estojos BGA, porque nem todos eles têm um interruptor para o lado oposto.
O host se comunica com o programador via USB através de vários pontos finais (pontos finais). O host sempre atua como um host. Através de um dos pontos de extremidade, o host envia um comando ao programador e, por meio dele, recebe a confirmação,
através de outro eles trocam dados entre si.

Os comandos de análise do host no módulo do programa são executados no método USB_ReceiveBuf_EP1RX_Parse ().

O pacote de comandos é descrito pela estrutura CMD_PROG e consiste em vários campos. Se o campo Cmd contiver 1, este é um comando para trabalhar com o microcircuito e o campo ProgProcNum nesse caso é o índice na matriz _progProcedures das estruturas PROG_PROC, em um dos campos em que um ponteiro para o comando a ser executado é armazenado.

No diretório com o programa "SUPERPRO 6100N" instalado, existe um subdiretório "\ lib". Ele com a extensão "* .bin" armazena arquivos de firmware XILINX para todos os tipos de chips suportados pelo programador. Entre eles, existem dois firmware universais para verificar o contato das pernas do microcircuito com os contatos das tomadas no adaptador.

Este é "GENERAL ~ .BIN" com um pull-up interno para todas as pernas pull-up do XILINX e "GENERAL_.BIN" com um pull pull-down interno.

A verificação do contato das pernas do microcircuito é realizada no método SOCKET_CkeckInsertIC () do módulo de software da seguinte maneira.

Primeiro, o firmware “GENERAL_.BIN” é carregado no XILINX e, com sua ajuda, todas as pernas do FPGA conectadas ao soquete são configuradas para saída e o “1” lógico é fornecido a eles. Por sua vez, cada perna do FPGA é reconfigurada para entrada, um nível lógico é lido a partir dele e, em seguida, “1” é novamente emitido para essa perna.

Se a perna do microcircuito tiver contato elétrico com a perna correspondente, então “1” deve ser lido (através dos diodos de proteção internos do microcircuito de todas as outras pernas). E na ausência de contato, devido ao fato de que todos os pinos do FPGA são puxados para o chão, "0" será lido a partir desta entrada. Depois disso, uma matriz de níveis lógicos lidos dessa maneira é enviada ao host e processada lá. A seguir, a execução da operação especificada continua ou é exibida uma mensagem sobre o não VKontakte das pernas correspondentes do microcircuito no soquete.
Após passar com êxito neste teste, o host envia o firmware para o XILINX correspondente ao chip instalado no adaptador ao programador.

A compilação de um programa para FPGA no ISE 10.1 (execução sequencial de procedimentos de síntese (Synthesize), implementação de um design (Implement Design) e geração de arquivos de programação (Gerar arquivo de programação)) cria um arquivo de configuração binária “xeltek.bin” de 78756 bytes no diretório do projeto. Para isso, nas propriedades do processo “Gerar arquivo de programação” na janela “Processos” na categoria “Opções gerais”, duas opções devem ser definidas: “Criar arquivo de bit” e “Criar arquivo de configuração da Bibary”.

Não se sabe por que motivos, mas os programadores do XELTEK decidiram modificar os arquivos assim obtidos espelhando todos os bits em cada byte.

Se, por qualquer motivo, você precisar "espelhar" seu próprio arquivo dessa maneira, ou "espelhar" o arquivo do diretório "\ lib" de volta à visualização normal, no software no menu "XILINX", existe para esse efeito o item "Bitstream Converter" (no final do nome o arquivo resultante está sublinhado).

Para trabalhar com o chip SDED5 no nível físico, os quatro métodos a seguir são implementados no módulo de software:

- PROGPROC_FLWRITE_IO_WORD () - grava uma palavra (16 bits) no endereço especificado
- PROGPROC_FLREAD_IO_WORD () - lê a palavra (16 bits) no endereço especificado
- PROGPROC_hal_blk_write_nor () - escreve um ou mais setores (512 bytes cada) no endereço especificado
- PROGPROC_hal_blk_read_nor () - lê um ou mais setores (512 bytes cada) no endereço especificado

Para interagir com o FPGA XILINX em nosso firmware, identificamos quatro registros (portas de E / S, descritas no arquivo common.h para fontes ARM).

- _IC_ADDR (0x30000010)
- _IC_DATA (0x30000012)
- _IC_CTRL (0x30000014) // Saída: 0 - WE, 1 - 0E, 2 - CE, 3 - RSTIN; Em: 0 - OCUPADO
- _IC_ENABLE (0x30000016) // In: 7 - Permissão de trabalho (0 - ativo, 1 - todas as pernas no soquete em Z)

_IC_ADDR e _IC_DATA são endereços de 16 bits e registradores de dados para o chip programável SDED5;
_IC_CTRL - registro de controle de 8 bits através do qual os sinais WE, OE, CE e RSTIN são configurados e o sinal BUSY é lido a partir do SDED5.

Os módulos de software originais usam endereços de 0x30000000 a 0x3000000E para se comunicar com FPGAs. O CPLD com a inscrição XELTEK é instalado como um decodificador de endereço no programador e, como não conhecemos seu firmware, usamos endereços de 0x30000010 para reduzir a probabilidade de consequências inesperadas de manifestar a lógica de comportamento de outra pessoa ao usar endereços "padrão".

Após carregar o firmware no FPGA, todas as saídas do FPGA conectadas às pernas do microcircuito no soquete estão no estado Z e para começar a trabalhar com ele, é necessário ativar a resolução gravando zero no sétimo bit do registro _IC_ENABLE.

O algoritmo de todo o sistema pode ter a seguinte aparência.

1. Depois de iniciar o software no host, ele verifica se há uma conexão com o programador via USB e exibe a mensagem correspondente na barra de status na parte inferior da janela principal
   (o programador pode ser conectado após o início do programa).
2. O usuário seleciona o tipo de chip com o qual pretende trabalhar.
3. No banco de dados (no caso mais simples, apenas no arquivo), o microcircuito selecionado corresponde ao tipo de adaptador necessário e uma solicitação é enviada ao programador para o tipo de adaptador instalado nele.
4. O programador solicita ao adaptador seu tipo e envia essas informações de volta ao host, onde essas informações são comparadas com as encontradas no banco de dados e, se os tipos de adaptadores corresponderem, o trabalho continuará.
5. Para cada tipo de microcircuito selecionado no software, um menu correspondente deve ser exibido com os comandos disponíveis para esse microcircuito (leitura, gravação, verificação de limpeza, comparação, etc.).
6. Quando você seleciona um item de menu para trabalhar com o microcircuito, o comando correspondente é enviado ao programador, após o qual o programador primeiro verifica o contato elétrico dos contatos dos soquetes com as pernas do microcircuito e, em seguida, se for bem-sucedido, executa esse comando.

Nos códigos-fonte anexados ao artigo, para simplificar a tarefa, pontos do segundo ao quinto, inclusive, não são implementados.

Sumário

Não tivemos a tarefa de integrar o módulo de software no software original,
portanto, o material descrito neste artigo não afirma ser uma solução completa.
Esperamos que as informações aqui apresentadas sejam úteis para uma determinada categoria de leitores e, da melhor maneira possível e com a disponibilidade de tempo livre, tentaremos responder às suas perguntas.

Obrigado pelo seu interesse!

Recursos

1 PDF - Unidade flash incorporada (EFD) mDOC H3 com software de gerenciamento de flash incorporado TrueFFS
2) PDF - Programação de memórias flash mDOC H3 usando programadores de dispositivos Dataman
3) PDF - Software_Utilities_TrueFFS_7.1
4) Software de controle Dataman - PG4UW
5) Implementação do driver mDOC H3 para Linux (o desempenho não foi testado)
6 Arquivos de origem do programador host (Visual Studio 2017).
7) Arquivos de origem do módulo de software (IAR Embedded Workbench for ARM v8.30.1).
8) Arquivos de origem para FPGA XILINX XC2S50E (XILINX ISE 10.1).