Implementação JTAG em dispositivos Arm Core

Este artigo irá ensiná-lo sobre a interseção entre JTAG e dispositivos centrais Arm, com atenção especial para a Interface de Depuração Arm ou ADI.

Até agora, em nossa série em JTAG, vimos o padrão IEEE 1149.1, incluindo o controlador de porta de acesso de teste (TAP) e a máquina de estado TAP. Em seguida, revisamos as diferentes interfaces físicas disponíveis para trabalhar com JTAG, incluindo pinagens comuns para conectores e as interfaces JTAG e sondas de depuração disponíveis no mercado.

Neste artigo, vamos nos afastar um pouco do padrão JTAG e, em vez disso, ver como o JTAG é implementado nos onipresentes dispositivos de núcleo ARM.

O que é Arm?

Arm refere-se a uma arquitetura de processador, junto com uma grande quantidade de propriedade intelectual relacionada ao microprocessador e às interfaces do microcontrolador. Onde os PCs de consumo tendem a usar processadores derivados de x86, ou PowerPC ou MIPS, a eletrônica embarcada é mais frequentemente implementada com processadores Arm-core.

O “núcleo” dos processadores é distribuído para fabricantes como ST Microelectronics ou NXP, e esses fabricantes adicionam recursos periféricos adicionais, como interfaces I2C e SPI, ADCs e DACs, interfaces USB e assim por diante.

Arquiteturas de braço são versionadas como ARMv, exemplos sendo ARMv2 (datando de 1987), ARMv6 (processadores produzidos em 2002-2005) e assim por diante, e os núcleos de processador que utilizam essas arquiteturas são marcados como série ARMx (ARM1, ARM6, ARM7), e mais recentemente como a série ARM Cortex-A / R / M para aplicativos de alto desempenho (Cortex-A), em tempo real (Cortex-R) e microcontroladores (Cortex-M). O versionamento da arquitetura segue a nomenclatura do sufixo Cortex, tornando-se versões como ARMv6-M, ARMv7-R, ARMv7-A.

A interface de depuração da Arm recebe o nome de Arm CoreSight Architecture; isso inclui a interface de depuração (Arm Debug Interface, ADI), macrocélulas de rastreamento incorporadas (ETM), portas de rastreamento seriais de alta velocidade (HSSTP) e arquitetura de rastreamento de fluxo de programa CoreSight. O ADI forma a base para operações de depuração com processadores Arm-core, e parte deste padrão inclui uma interface JTAG, bem como a alternativa Serial Wire Debug (SWD). O tópico deste artigo é o ADI e, particularmente, as camadas de interface de hardware.

Introdução à Interface de Depuração Arm (ADI)

O Arm Debug Interface (ADI) é uma especificação da interface de hardware e da interface lógica para depuração entre um host e um ou mais dispositivos. Atualmente, a maioria dos processadores está implementando ADIv5 (especificado no Arm IHI0031E), enquanto o ADIv6 mais recente (consulte Arm IHI0074C) está sendo gradualmente implementado. Por ser mais popular, vamos nos concentrar aqui no padrão ADIv5.

A ADI define uma porta de acesso de depuração (DAP), composta de uma porta de depuração (DP) e portas de acesso (APs). O DAP é a “unidade” primária da interface de depuração. Um determinado dispositivo terá uma porta de depuração, que lida com a conexão física com um depurador, bem como várias portas de acesso que fornecem acesso aos recursos do sistema, como registros de depuração, registros de porta de rastreamento, uma tabela ROM ou memória do sistema. Assim, o DP inclui a conexão física (JTAG, SWD), bem como alguns registros embutidos, e cada AP tem suas conexões com o sistema e vários de seus próprios registros.

No ADIv5, existem dois tipos de portas de depuração e (em termos gerais) três tipos de portas de acesso. Os DPs podem ser JTAG-DPs ou SWD-DPs, nomeados de acordo com a interface usada na conexão com o DAP de fora do dispositivo. Os APs podem ser MEM-APs, fornecendo acesso a recursos por endereçamento (análogo ao mapeamento de memória, daí o nome), JTAG-APs, permitindo que as cadeias de varredura JTAG sejam conectadas a toda a unidade de depuração (o DAP) e específico do fornecedor APs, que não são especificados pela Arm. MEM-APs são de longe os mais comuns e úteis, então não iremos cobrir os outros tipos aqui.

No contexto do JTAG, esperamos que a Interface de Depuração forneça códigos de instrução JTAG, bem como recursos JTAG específicos do fornecedor. Na verdade, o padrão ADIv5 fornece as seguintes instruções:

• EXTEST (0b00000000)
• AMOSTRA (0b00000001)
• PRÉ-CARREGAR (0b00000010)
• INTEST (0b00000100)
• CLAMP (0b00000101)
• HIGHZ (0b00000110)
• ABORT (0b11111000)
• DPACC (0b11111010)
• APACC (0b11111011)
• IDCODE (0b11111110)
• BYPASS (0b11111111)

Além disso, os registros de dados JTAG incluem:

• ABORT (35 bits), registre-se para forçar um aborto da porta de acesso
• DPACC (35 bits), registro de acesso de leitura / gravação da porta de depuração
• APACC (35 bits), registro de acesso de leitura / gravação da porta de acesso
• IDCODE (32 bits)
• BYPASS (1 bit)

O que deve se destacar aqui são as instruções DPACC e APACC, e os registros de dados associados. DPACC (Debug Port Access) e APACC (Access Port Access) são as instruções / registros usados ​​para passar comandos para o DP e APs associados de um dispositivo. Ao definir valores diferentes nos registros de dados DPACC ou APACC, o depurador pode executar diferentes operações, geralmente interagindo com os registros dos próprios DP e APs. Observe a diferença entre esses registros DPACC e APACC (registros JTAG) e os registros embutidos nos DPs e APs.

A metodologia geral aqui é que o depurador usa a interface JTAG ou SWD para executar instruções passando pela máquina de estado TAP, então as instruções pegam os dados e os carregam no DP ou AP e, dependendo dos dados, diferentes registros dentro o DP ou AP são acessados, fornecendo o link desejado para o sistema.

Então, quais são os registros DP e AP? Os registros DP disponíveis incluem:

• CTRL / STAT, usado para controlar e obter informações de status sobre o DP
• DLCR, registro de controle de link de dados, controla o modo de operação do link de dados
• DLPIDR, registro de identificação do protocolo de link de dados, informações sobre a versão do protocolo
• DPIDR, registro de identificação de porta de depuração, informações de porta de depuração
• EVENTSTAT, registro de status de evento, usado pelo sistema para sinalizar um evento para o depurador externo
• RDBUFF, registro Read Buffer, fornece uma operação de leitura; dependente de DP (JTAG ou SWD)
• SELECT, AP Select register, seleciona uma porta de acesso e os bancos de registro ativos com aquele AP; seleciona o banco de endereço DP
• TARGETID, fornece informações sobre o destino quando o host está conectado a um único dispositivo

Enquanto os registros MEM-AP são:

• Registro de palavras de controle / status (CSW, 0x00), contém informações de controle e status
• Registro de endereço de transferência (TAR, 0x04), contém o endereço para o próximo acesso ao sistema de memória ou recurso do sistema
• Registro de leitura / gravação de dados (DRW, 0x0C), define a leitura ou escrita do endereço no TAR - se você ler DRW, o acesso é definido para ler; se você escrever para DRW, o acesso é definido para escrever
• Registradores de dados armazenados (BD0 a BD3, 0x10, 0x14, 0x18, 0x1C) fornecem acesso direto de leitura ou gravação a quatro blocos de memória de 32 bits, começando no endereço em TAR
• Registro de configuração (CFG, 0xF4), informações sobre a configuração MEM-AP
• Registro de Debase Base Address (BASE, 0xF8), ponteiro para sistema de memória, seja o início de um conjunto de registros de depuração ou o início de uma tabela ROM
• Registro de identificação (IDR, 0xFC), identifica o MEM-AP.

As conexões são mostradas esquematicamente na Figura 1, abaixo.

Figura 1. Diagrama da interface de depuração do braço, resumindo as conexões. Nota:nem todos os registros são mostrados para DPs e APs.

Detalhes dos registros DP / AP e o mapeamento de memória podem ser encontrados na especificação, IHI 0031E. Em vez de entrar em detalhes, gostaria de me concentrar no outro tipo de porta de depuração, o SWD-DP, e como ele implementa JTAG usando apenas dois fios.

Depuração de fio serial (SWD)

Enquanto o JTAG-DP é um exemplo comum e familiar de uma interface de depuração, mais relevante para nossa discussão é a alternativa JTAG definida para dispositivos Arm, o Arm Serial Wire Debug (SWD). SWD foi desenvolvido como uma interface de dois fios para dispositivos Arm-core com contagens de pinos limitadas. Como os microcontroladores tendem a ser bastante densos em periféricos, a maioria dos dispositivos Cortex-M implementará SWD no lugar de JTAG completo para economizar o espaço dos pinos. Então, como esse protocolo funciona?

SWD é especificado na especificação ADIv5 (capítulo B4). Os pinos TDI e TDO da JTAG são substituídos por um único pino bidirecional denominado SWDIO; o pino de seleção do modo de teste (TMS) é removido inteiramente; e o relógio (TCK) permanece o mesmo (CLK ou SWCLK renomeado). Assim, o SWD usa apenas dois pinos em comparação com os quatro pinos usados ​​no JTAG. Para fazer esse trabalho, o SWD depende da natureza repetitiva das operações JTAG:a máquina de estado é manipulada, os dados são transferidos para dentro ou para fora e o processo se repete. A diferença com o SWD é que não há máquina de estado. Em vez disso, os comandos são emitidos em série por SWDIO e, em seguida, esse mesmo pino é usado para ler ou gravar dados.

Existem três fases para a comunicação SWD:solicitação de pacote, confirmação e transferência de dados. Durante a solicitação de pacote, a plataforma host emite uma solicitação ao DP, e isso deve ser seguido por uma resposta de reconhecimento. Se a solicitação de pacote foi uma solicitação de leitura ou gravação de dados e houve um reconhecimento válido, o sistema entra na fase de transferência de dados, onde os dados são marcados para entrada (gravação) ou saída (leitura) por meio de SWDIO. Após uma transferência de dados, o host é responsável por iniciar uma solicitação de pacote ou conduzir a interface SWD com ciclos ociosos (clocking SWDIO LOW). Uma verificação de paridade é aplicada a solicitações de pacotes e fases de transferência de dados.

Os detalhes do SWD são mais bem compreendidos ao ver um diagrama de tempo, mostrado na Figura 2.

Figura 2. Diagramas de tempo mostrando operações de leitura e gravação para Serial Wire Debug. [Clique para ampliar]

As operações de leitura e gravação começam da mesma forma, começando com o host conduzindo a linha SWDIO para um bit de início, que é um sinal HIGH. Isso é seguido pela configuração, incluindo o bit de acesso AP ou DP (APnDP), o bit de leitura ou gravação (RnW), o endereço (A [2:3]), um bit de paridade (PAR) e um bit de parada ( um sinal LOW), seguido finalmente por um bit Park, que é quando o host conduz a linha HIGH antes que a linha entre em rotação. Durante a recuperação, nem o alvo nem o host têm permissão para conduzir a linha.

Dependendo do valor de RnW, uma operação de leitura ou gravação é selecionada. Se estiver gravando, o destino fornece um sinal ACK de 3 bits, então há outro período de retorno, seguido pelos dados de 32 bits a serem gravados (WDATA) e um bit de paridade. Se estiver lendo, o destino fornece um ACK e, a seguir, continua a conduzir a linha com os dados lidos de 32 bits (RDATA), seguido por um bit de paridade. Se ocorrer um erro, os bits ACK indicarão a falha e o host pode tentar reiniciar a operação. Observe que WDATA e RDATA são transmitidos primeiro pelo bit menos significativo (LSb), indicado na Figura 2 escrevendo WDATA [0:31] em vez de WDATA [31:0].

O documento Arm IHI0031E fornece diagramas de tempo adicionais para esclarecer vários casos de comunicação, mas os casos acima são os principais casos de uso. É importante notar que existem (no momento da escrita) duas versões do SWD; SWDv1 oferece suporte a apenas uma conexão entre um host e um destino (ponto a ponto), enquanto o SWDv2 implementa comunicação de host único e múltiplos alvos (multidrop). A versão 2 é quase compatível com a versão 1, exceto alguns casos extremos.

Outras variantes de JTAG

SWD não é a única variante de dois fios do padrão JTAG IEEE 1149.1. Notavelmente, o padrão IEEE 1149.7 fornece uma interface JTAG de contagem reduzida de pinos (2 fios). Outros padrões 1149.x como IEEE 1149.4 (Padrão para Barramento de Teste de Sinal Misto) e IEEE 1149.6 (Padrão de Boundary-Scan de Redes Digitais Avançadas) foram desenvolvidos nas últimas duas décadas e fornecem funcionalidade adicional para aplicativos mais envolvidos. Isso inclui coisas como testes analógicos de varredura de limite e recursos aprimorados para linhas diferenciais e acopladas a CA.

Os padrões mais atualizados estão disponíveis no site da IEEE Standards Association.

Conclusão

Isso conclui nossa cobertura de JTAG e SWD. Ao longo desta série, aprendemos de onde vem o JTAG, como funciona e como é usado para depurar e programar dispositivos. Vimos as conexões físicas para JTAG, incluindo os conectores e interfaces disponíveis, tanto comerciais quanto de código aberto. Finalmente, concluímos com uma visão geral da implementação JTAG para as populares tecnologias de núcleo do processador Arm, incluindo a interface SWD de dois fios.

A partir daqui, podemos sair e usar com segurança os recursos de depuração e programação de nossos dispositivos embarcados, aprendendo os detalhes para diferentes implementações e fazendo o melhor uso de nosso tempo.