Openocd download binary option

15 Comandos Gerais Os comandos documentados neste capítulo aqui são comandos comuns que você, como um ser humano, pode querer digitar e ver a saída de. Os comandos de tipo de configuração são documentados em outro lugar. Comandos de Origem de Comandos Os comandos OpenOCD podem ocorrer em um script de configuração (discutido em outro lugar) ou digitados manualmente por um humano ou fornecidos programaticamente, ou através de uma das várias Portas TCP / IP. Do humano Um ser humano deve interagir com a interface telnet (porta padrão: 4444) ou via GDB (porta padrão 3333). Para emitir comandos a partir de uma sessão do GDB, use o comando monitor, p. Use monitor poll para emitir o comando poll. Toda a saída é transmitida através da sessão do GDB. Interface de Máquina A interface de Tcl interfacersquos é para ser uma interface de máquina. A porta Tcl padrão é 5555. 15.1 Comandos do Servidor Sai da sessão telnet atual. Sem parâmetros, imprime texto de ajuda para todos os comandos. Caso contrário, imprime cada texto de ajuda contendo string. Nem todo comando fornece texto de ajuda. Os comandos de configuração e os comandos válidos a qualquer momento são explicitamente anotados entre parênteses. Na maioria dos casos, essa restrição não é listada, isso indica comandos que só estão disponíveis após a conclusão da etapa de configuração. Aguarde pelo menos milissegundos msec antes de retomar. Se ocupado for passado, ocupado-espere em vez de dormir. (Esta opção é fortemente desencorajada.) Útil em conexão com arquivos de script (comando de script e configuração de nome de destino). Feche o servidor OpenOCD, desconectando todos os clientes (GDB, telnet, outros). Se o erro de opção for usado, OpenOCD retornará um código de saída diferente de zero para o processo pai. Exibir nível de depuração. Se n (de 0..3) for fornecido, defina-o para esse nível. Isso afeta o tipo de mensagens enviadas para o log do servidor. Nível 0 é apenas mensagens de erro nível 1 adiciona advertências nível 2 adiciona mensagens informativas eo nível 3 adiciona mensagens de depuração. O padrão é o nível 2, mas pode ser substituído na linha de comando junto com a localização desse arquivo de log (que normalmente é a saída padrão do servidor). Consulte Executando. Registra uma mensagem em quotuserquot prioridade. Mensagem de saída para stdout. A opção quot-nquot suprime a linha de partida. Redirecionar log para filename o canal de saída do log inicial é stderr. Comando: addscriptsearchdir diretório Adicionar diretório ao caminho de pesquisa de arquivo / script. Especifique o endereço pelo nome para ouvir as conexões TCP / IP de entrada. Por padrão, OpenOCD irá ouvir em todas as interfaces disponíveis. 15.2 Tratamento do estado de destino Nesta seção, ldquotargetrdquo se refere a uma CPU configurada como mostrado anteriormente (consulte Configuração da CPU). Esses comandos, como muitos, implicitamente referem-se a um alvo atual que é usado para executar as várias operações. O destino atual pode ser alterado usando o comando targets com o nome do destino que deve se tornar atual. Acesse um único registro por número ou por seu nome. O alvo geralmente deve ser interrompido antes do acesso aos registros de núcleo da CPU é permitido. Dependendo do hardware, alguns outros registradores podem estar acessíveis enquanto o alvo está sendo executado. Sem argumentos. Lista todos os registros disponíveis para o destino atual, mostrando o número, nome, tamanho, valor e status do cache. Para entradas válidas, um valor é mostrado entradas válidas que também são sujas (e serão escritas mais tarde) são sinalizadas como tal. Com número / nome. Exibir esse valor registerrsquos. Use argumento de força para ler diretamente do destino, ignorando qualquer cache interno. Com o número / nome e valor. Set registerrsquos valor. As gravações podem ser mantidas em um cache de writeback interno para OpenOCD, de modo que a configuração do valor marca o registro como sujo em vez de imediatamente liberar esse valor. A retomada da execução da CPU (inclusive por um único passo) ou a ativação do módulo relevante liberará esses valores. Núcleos podem ter surpreendentemente muitos registros em sua infraestrutura de depuração e rastreamento: O comando Halt envia primeiro uma solicitação de parada para o destino, o que não significa. Caso contrário, estes comportam-se da mesma forma: aguarde até ms milissegundos, ou 5 segundos se não houver nenhum parâmetro, para o alvo parar (e entrar no modo de depuração). Usando 0 como o parâmetro ms impede OpenOCD de espera. Aviso: Em núcleos ARM, o software que usa a operação de espera para interrupção muitas vezes bloqueia o acesso JTAG necessário por um comando de parada. Isso ocorre porque essa operação também coloca o núcleo em um modo de baixa energia através da ativação do clock do núcleo, mas o clock do núcleo é necessário para detectar transições de clock JTAG. Uma solução alternativa usa o clock adaptativo: quando o núcleo é interrompido, a operação é concluída, então os relógios JTAG são aceitos pelo menos até que o manipulador de interrupção seja concluído. No entanto, esta solução alternativa muitas vezes é inutilizável uma vez que o processador, placa e adaptador JTAG devem todos suporte JTAG adaptativo clocking. Além disso, ele não pode funcionar até que uma interrupção seja emitida. Uma solução mais completa é não usar essa operação enquanto você trabalha com um depurador JTAG. Os ambientes de tarefas geralmente possuem loops ociosos onde o corpo é a espera pela operação de interrupção. (Em núcleos mais antigos, é uma ação coprocessador núcleos mais novos têm uma instrução wfi.) Esses loops podem apenas remover essa operação, ao custo de maior consumo de energia (porque a CPU é desnecessariamente clock). Retomar o alvo na sua posição de código actual, ou o endereço opcional se for fornecido. OpenOCD aguardará 5 segundos para que o alvo seja retomado. Etapa única o destino em sua posição de código atual, ou o endereço opcional se for fornecido. Execute uma reinicialização tão dura quanto possível, usando SRST, se possível. Todas as metas definidas serão redefinidas e os eventos de destino dispararão durante a seqüência de reset. O parâmetro opcional especifica o que deve acontecer após a redefinição. Se não houver nenhum parâmetro, uma execução de reset será executada. As outras opções não funcionarão em todos os sistemas. Consulte Repor configuração. - run Deixar o alvo executar - parar Parar imediatamente o alvo - init Imediatamente parar o alvo e executar o script reset-init Comando: softresethalt Solicitando a parada de destino e executando uma reinicialização. Isso geralmente é usado quando um alvo não pode ser redefinido e interrompido. O alvo, depois de reiniciar é liberado começa a executar código. OpenOCD tenta parar a CPU e, em seguida, define o contador de programa de volta para o vetor de redefinição. Infelizmente, o código que foi executado pode ter deixado o hardware em um estado desconhecido. 15.3 Utilitários de E / S Esses comandos estão disponíveis quando OpenOCD é construído com --enable-ioutil. São principalmente úteis em alvos incorporados, notadamente o ZY1000. Hosts com sistemas operacionais têm ferramentas complementares. Nota: existem vários comandos adicionais. Acrescenta os parâmetros de seqüência de caracteres ao nome de arquivo do arquivo de texto. Cada cadeia, excepto a última, é seguida por um espaço. A última cadeia é seguida por uma nova linha. Lê e exibe o nome do arquivo de texto. Comando: cp srcfilename destfilename Copia o conteúdo do arquivo srcfilename para destfilename. Nenhuma descrição fornecida. Nenhuma descrição fornecida. Nenhuma descrição fornecida. Nenhuma descrição fornecida. Desvincula o nome do arquivo. Remove todos os dados no nome do arquivo. 15.4 Comandos de acesso à memória Estes comandos permitem acessos de um tamanho específico ao sistema de memória. Muitas vezes estes são usados ​​para configurar o alvo atual de alguma maneira especial. Por exemplo - pode ser necessário escrever certos valores no controlador SDRAM para ativar SDRAM. Use o comando targets (plural) para alterar o alvo atual. Em scripts de nível de sistema, esses comandos são obsoletos. Use seus irmãos de objeto TARGET para evitar fazer suposições sobre o que TAP é o destino atual ou sobre a configuração MMU. Comando: mdw phys addr count Comando: mdh phys addr count Comando: mdb phys addr count Exibir conteúdos do endereço addr. Como palavras de 32 bits (mdw), halfwords de 16 bits (mdh) ou bytes de 8 bits (mdb). Quando o destino atual tem uma MMU que está presente e ativa, addr é interpretado como um endereço virtual. Caso contrário, ou se o sinalizador phys opcional for especificado, addr é interpretado como um endereço físico. Se contar é especificado, exibe que muitas unidades. (Se você quiser manipular os dados em vez de exibi-lo, consulte as primitivas mem2array.) Grava o valor especificado (32 bits), halfword (16 bits) ou byte (8 bits), no endereço especificado addr. Quando o destino atual tem uma MMU que está presente e ativa, addr é interpretado como um endereço virtual. Caso contrário, ou se o sinalizador phys opcional for especificado, addr é interpretado como um endereço físico. 15.5 Comandos de carregamento de imagem Dump tamanho de bytes da memória de destino começando no endereço para o arquivo binário nomeado filename. Carrega uma imagem armazenada na memória por fastloadimage para o destino atual. Deve ser precedido por fastloadimage. Comando: fastloadimage nome do arquivo endereço bin ihex elf s19 Normalmente você deve usar loadimage ou carga GDB. No entanto, para fins de teste ou quando a sobrecarga de E / S é significativa (OpenOCD em execução em um host incorporado), armazenar a imagem na memória e fazer o upload da imagem para o destino pode ser uma maneira de carregar, por exemplo. Várias sessões de depuração quando o binário não é alterado. Argumentos são os mesmos que loadimage. Mas a imagem é armazenada na memória do host OpenOCD, isto é, não afeta o alvo. Essa abordagem também é útil quando se define perfil de desempenho de programação de destino como E / S e programação de destino podem facilmente ser perfilados separadamente. Comando: loadimage nome do arquivo endereço bin ihex elf s19 minaddr maxlength Carrega a imagem do arquivo nome do arquivo para a memória de destino deslocada pelo endereço do seu endereço de carga. O formato de arquivo pode ser opcionalmente especificado (bin. ihex elf ou s19). Além disso, os seguintes argumentos podem ser especificados: minaddr - ignore dados abaixo de minaddr (isto é w. r.t. para o endereço de endereço de carga de targetrsquos) maxlength - número máximo de bytes a carregar. Comando: nome do arquivo de testemunho bin ihex elf Exibe tamanhos de seção de imagem e endereços como se o nome de arquivo fosse carregado na memória de destino começando no endereço (o padrão é zero). O formato do arquivo pode ser opcionalmente especificado (bin. ihex ou elf) Comando: verifyimage nome do arquivo endereço bin ihex elf Verifique o nome do arquivo contra a memória de destino a partir do endereço. O formato de arquivo pode ser opcionalmente especificado (bin. ihex ou elf) Isto irá primeiro tentar uma comparação usando uma soma de verificação CRC, se isso falhar, tentará uma comparação binária. Comando: verifyimagechecksum nome do arquivo endereço bin ihex elf Verifique o nome do arquivo contra a memória de destino começando no endereço. 15.6 Comandos Breakpoint e Watchpoint Os CPUs geralmente tornam os módulos de depuração acessíveis através do JTAG, com suporte a hardware para um punhado de pontos de interrupção de código e pontos de observação de dados . Além disso, as CPUs quase sempre suportam pontos de interrupção de software. Sem parâmetros, lista todos os pontos de interrupção ativos. Else define um ponto de interrupção na execução de código começando no endereço para bytes de comprimento. Este é um ponto de interrupção de software, a menos que hw seja especificado, caso em que será um ponto de interrupção de hardware. (Veja armc vectorcatch ou ver xscale vectorcatch para mecanismos similares que não consomem pontos de interrupção de hardware.) Remova o ponto de interrupção no endereço. Remover o ponto de observação de dados no endereço Sem parâmetros, lista todos os pontos de observação ativos. Else define um ponto de observação de dados em dados do endereço para bytes de comprimento. O ponto de observação é um quotaccessquot watchpoint a menos que o parâmetro r ou w seja fornecido, definindo-o como respectivamente um ponto de observação de leitura ou gravação. Se for fornecido um valor, esse valor é usado para determinar se o ponto de observação deve disparar. O valor pode ser primeiro mascarado usando máscara para marcar campos ldquodonrsquot carerdquo. 15.7 Comandos Misc Os perfis amostrarão o contador do programa CPUrsquos o mais rápido possível, o que é útil para o perfilamento estocástico não intrusivo. Salva até 10000 amostras em nome de arquivo usando o formato ldquogmon. outrdquo. Parâmetros de início e fim opcionais permitem limitar o intervalo de endereços. Exibe uma seqüência de caracteres que identifica a versão deste servidor OpenOCD. Solicita ao alvo atual que mapeie o endereço virtual especificado para o endereço físico correspondente e exiba o resultado. Obtendo OpenOCD O OpenOCD está disponível em muitos formulários diferentes de vários locais, esta página deve servir como um guia direcionando você para a opção mais apropriada para o usecase . Ao relatar um bug ou pedir assistência através de qualquer meio (como a lista de endereços, o IRC ou o rastreador de problemas), informe sem ambiguidade qual versão você está usando e de onde a obteve. Se você não está preparado para recompilar a partir das fontes (that8217s muitas vezes necessárias para testar fora-de-árvore patches), por favor mencione isso também. Sistemas operacionais oficiais8217 repositórios OpenOCD se encaixa naturalmente no ecossistema de software livre, portanto está disponível de forma apropriada em sistemas operacionais populares em seus respectivos repositórios. Em outras palavras, a instalação do OpenOCD é tão fácil quanto executar um comando openocd do apt-get install no Debian GNU / Linux (e derivados), emerge openocd no Gentoo, opkg install openocd no OpenWrt etc. O mesmo se aplica aos usuários do OS X que executam o Homebrew (ou MacPorts) e usuários do Windows que possuem o MSYS2 instalado. Se o sistema operacional de sua escolha não tiver o OpenOCD, sinta-se livre para se tornar um mantenedor de pacotes, a comunidade do OpenOCD irá apreciar seu envolvimento e fornecer assistência se você enfrentar quaisquer problemas. Código fonte O repositório oficial do código fonte do Git está disponível em SF. net. Além disso (principalmente para os usuários atrás de firewalls corporativos), there8217s um espelho oficial hospedado por repo. or. cz. Alguns dos patches propostos para inclusão a montante mas ainda não autorizados estão disponíveis no servidor de revisão Gerrit. Pacotes binários não oficiais Algumas circunstâncias especiais podem tornar o uso de um gerenciador de pacotes ou auto-compilação OpenOCD impraticável, então vários membros da comunidade agradável fornecem compilações binárias atualizadas regularmente em seus sites. Acessando ARM-Controladores com OpenOCD por Martin THOMAS changelog: 20090430 - STM32 flash 20080811 - Configuração para LPC23xx / 24xx com OpenOCD moderno, scripting, Observações sobre Eclipse 20080409 - algumas observações na introdução, pdf - Documentação 20080404 - observações adicionadas sobre comandos novos e passados ​​- AVISO: Até agora eu não testei scripts usando flash erasesector ou flash writebank, então as modificações são apenas preliminares para manter esta página pelo menos um pouco atualizada. 20070822 - definição do flash de LPC2k e STR7 para novas versões do OpenOCD, flash marcado como depreciado e alternativas de menção, link para documentação-wikki 20070504 - CFI 200705xx - sobre o genaration de script fly em Makefile 20070518 - mais sobre lockbits e nvmbits em AT91SAM - A seção OpenOCD criada por Dominic Rath é um gdb-server e flash-utility para ARM-Controllers. Suporta controladores ARM7 e ARM9. Os dispositivos baseados em Wiggler e FTDI2232 podem ser usados ​​como interfaces de hardware. Os host-plattforms suportados são sistemas Linux / Unix ou sistemas MS-Windows (nativos e cygwin). Michael Fischer criou uma página na qual ele descreve como o OpenOCD pode ser usado em conjunto com o depurador GNU (gdb, Insight-gdb, ddd etc.). A seção a seguir descreverá métodos de como usar a funcionalidade de programação flash no OpenOCD. OpenOCD está sob grande desenvolvimento e é difícil manter esta página atualizada. Mas os desenvolvedores mantêm uma documentação. Se você estiver construindo OpenOCD você mesmo pode criar o documento com fazer pdf. Algumas ferramentas são necessárias para criá-lo (eu uso MiKTeX). Ler esp. O capítulo Deprecated / Removed Commands do documento se você receber mensagens de erro ao usar a configuração / scripts mostrada abaixo. Programação em Flash com OpenOCD O OpenOCD suporta a programação flash nos controladores NXP / Philips LPC2000, Atmel AT91SAM7 e ST STR7 ARM7 (versão SVN100). A programação em Flash pode ser feita acessando o OpenOCD-telnet-server, mas eu prefiro um método onde a programação flash é automatizada. Isto é muito conveniente quando se trabalha com make. Se tudo estiver configurado corretamente, um programa make simples transferirá o código binário para a memória flash. Instalando o OpenOCD em um sistema MS-Windows Os métodos descritos nesta pequena introdução foram testados em um sistema Windows 2000 com uma interface JTAG do tipo Wiggler (Olimex ARM-JTAG) e um hardware baseado em FTDI2232 (ie JTAGKEY, WINARM - JTAG). O uso do OpenOCD é basicamente o mesmo em sistemas Linux / Unix. Você pode obter o código-fonte OpenOCD mais recente do sistema SVN da berliOS e compilá-lo e instalá-lo você mesmo. Para MS-Windows Michael Fischer fornece uma versão pré-compilada que inclui um software de configuração. Links estão disponíveis na minha página ARM-projects (veja Links). Às vezes eu atualizo um binário para o MS-Windows também, vejo minha página do WinARM Em sistemas MS-Windows modernos como NT, 2000 ou XP, um driver especial deve ser instalado para a interface de hardware do tipo Wiggler. Este driver é chamado giveio e está incluído na distribuição binária de Michael Fischer. O software de configuração irá perguntar se o driver deve ser instalado. Mas também pode ser instalado lateron com install-giveio. bat (privilégios de administrador necessários apenas para instalação). Para interfaces baseadas em FTDI FT2232, como as de Amontec, Olimex, Signalyzer e myevertool. de, os drivers FTDI devem ser instalados. O pacote M. Fischers inclui os drivers para alguns dispositivos (a principal diferença é o VID / PID, os drivers de hardware reais são aqueles disponíveis no FTDI com arquivos inf adicionais). Basicamente três arquivos são necessários para uma programação flash automatizada: openocd. exe em si (giveio tem que ser instalado ao usar um hardware do tipo Wiggler em sistemas Win32, o driver FTDI deve ser instalado ao usar hardware baseado em FT2232). Michael Fischer decidiu criar dois binários, um para hardware tipo Wiggler conectado à porta paralela e outro para dispositivos baseados em FT2232. Um arquivo de configuração com definições da interface de hardware (ou seja, uma interface de tipo Wiggler) eo controlador de destino um arquivo de script com os comandos de flash Gravação de memória flash interna NXP / Philips LPC2000 Todos os arquivos mencionados nesta seção estão disponíveis Para download (veja abaixo). Um exemplo simples de aplicativo também está incluído no arquivo de arquivos. Target-controller é um NXP LPC2138 em uma placa Keil LPC2130. Mas o método básico pode ser usado para todos os controladores LPC2000 após mudanças mínimas. Além dos três arquivos basicamente necessários para a programação flash automatizada, adicionei alguns pequenos arquivos de cola para tornar a configuração e o uso um pouco mais fáceis. O primeiro arquivo openocdinstallinfo. cmd é arquivo-batch simples para definir algumas variáveis. Todos os arquivos cmd são feitos para o sistema operacional MS Windows, mas os usuários do Unix terão a idéia de como criar seus próprios shell-scripts. As localizações dos binários do OpenOCD e da interface JTAG utilizada são dadas no arquivo: OpenOCD é chamado de openocdgoflash. cmd: Como você pode ver o script apenas chama as informações de instalação para definir as variáveis ​​de configuração depois que ele chama o OpenOCD - binary com o arquivo de configuração para o JTAG-hardware usado (configurado). Os arquivos openocdlpc2138flashftdi. cfg e openocdlpc2138flashwigger. cfg são basicamente os mesmos e apenas diferem na seção de definição de interface. Aqui apenas é mostrada a configuração para o hardware baseado em FTDI FT2232. O arquivo de configuração para o hardware do tipo Wiggler pode ser encontrado no arquivo-arquivo. No conteúdo listado abaixo você vai notar que o jtagspeed foi definido como 3, isso foi descoberto por tentar e erro, as configurações 0,1 e 2 não funcionou formulário me com um JTAGKEY e WinARM-JTAG (no cfg Para o Wiggler-hardware jtagspeed 0 foi usado e trabalhado de forma confiável). O arquivo openocdlpc2138flash. script inclui os comandos que são chamados em reset (uma vez que resetandinit é dado como parâmetro para o destino). Um exemplo para um programa-alvo (make programa) no makefile. Faça shure o arquivo main. bin está no formato raw-binary (objcopy formato-opção binário): O exemplo é um pequeno programa para um NXP LPC2138 na placa de avaliação Keil LPC2138. Mas deve ser bastante portátil e pode ser usado para outros controladores NXP com pequenas modificações. Souce-code, linker-scripts, makefile e OpenOCD-config / - script estão incluídos. Download (zip, timestamp 20061013) NXP LPC23xx / 24xx Versões mais recentes do OpenOCD oferecem TCL-scripting. A configuração a seguir usa scripts e não funcionará com versões mais antigas do OpenOCD. Leia os comentários abaixo para mais informações. Interface / jtagkey. cfg é um arquivo da biblioteca OpenOCD. OpenOCD inicia pesquisa de arquivos no nível do diretório acima de openocd. exe em sistemas MS Windows (configuração padrão). Portanto, se o openocd. exe estiver localizado, por exemplo, em C: myutilsembbin, o arquivo jtagkey. cfg deve estar localizado em C: myutilsembinterface. Se você não tiver o arquivo em mãos, descomente as linhas de interface no arquivo de configuração fornecido acima. Uma vez que OpenOCD é anexado com: a programação instantânea pode ser feita via interface telnet com: A partir da linha de comando / makefile apenas use De causar qualquer outro arquivo de interface da interface-library, um self-written interface-file ou uma interface-section No openocd. cfg pode ser configurado também ao usar outras interfaces como por exemplo um Wiggler. Mas eu acabei de testar com o cabo da Amontec. Observe também que meus comandos definidos pelo usuário para piscar incluem um comando de verificação. Isso falhará se o OpenOCD tiver calculado a soma de verificação no flash-address 0x00000014 on-the-fly durante a programação flash, devido à opção calcchecksum dada na definição do banco e o valor na carga-imagem (hex, elf, bin file) Não corresponde ao valor calculado. A falha de verificação pode ser evitada ajustando-se a soma de verificação correta no código do montador (.ltchecksum da palavra-chave na entrada reservada na tabela) assim que a carga-imagem e o índice-flash após a escrita corresponderão. Eu não recomment para remover a opção calcchecksum ou para desativar verificar porque o destino não vai começar a partir de flash após redefinir se a soma de verificação em 0x14 é inválido e problemas durante a programação flash não podem ser detectados. Minhas configurações para uma configuração de depuração com atualização de memória flash no Eclipse usando o plug-in Eclipse C / C GDB Hardware Debugging (isso não é plugin Zylins): Testado com Eclipse 3.4, CDT 5.0, C / C GDB Hardware Debugging 5.0, OpenOCD SVN971 (Win32 / MinGW), braço-nenhum-eabi-gdb 6.8 de Codesourcery G lite para ARM Q3 / 2007, Amontec JTAGKey, NXP LPC2378 e Olimex LPC-2378-STK. BTW: o Target Managment Terminal é um Eclipse-plugin útil que oferece serial-communication e telnet de dentro do Eclipse (uma View). Pode ser usado para comunicar com OpenOCD e para printf-debugging via UART. Certifique-se de instalar o RXTX End-User Runtime de acesso à porta COM no Win32. Gravação Atmel AT91SAM7S memória flash interna Os arquivos e a configuração necessários para gravar a memória flash interna de um controlador AT91SAM7 são basicamente os mesmos descritos na seção anterior. O arquivo-arquivo inclui todos os arquivos necessários juntamente com algum código de exemplo (link de download abaixo). De acordo com uma mensagem no OpenOCD-fórum, o procedimento também pode ser usado para programar AT91SAM7X256 / AT91SAM7XC256. O exemplo é preparado para ser usado com os binários OpenOCD pré-compilados de Michale Fischer (link abaixo). E inclui um conjunto de arquivos para fazer uso e configuração tão fácil quanto possível (espero). O primeiro arquivo openocdinstallinfo. cmd é arquivo-batch simples para definir algumas variáveis. Todos os arquivos cmd são feitos para o sistema operacional MS Windows, mas os usuários do Unix terão a idéia de como criar seus próprios shell-scripts. As localizações dos binários do OpenOCD e da interface JTAG usada são dadas no arquivo: OpenOCD é chamado de openocdgoflash. cmd: Como você pode ver o script apenas chama o install-info então defina as variáveis ​​de configuração depois disso chama o OpenOCD - binary com o arquivo de configuração para o JTAG-hardware usado (configurado). Os arquivos openocdat91sam7sflashftdi. cfg e openocdat91sam7sflashwigger. cfg são basicamente os mesmos e apenas diferem na seção interface-defintion. Aqui apenas a configuração para o hardware baseado em FTDI FT2232. O arquivo de configuração para o hardware do tipo Wiggler pode ser encontrado no arquivo de arquivos. O arquivo openocdat91sam7sflash. script inclui os comandos que são chamados em reset (uma vez que resetandinit é dado como parâmetro para o destino). O register-writes para o init ecr foi encontrado no pacote openocd. Acabei de adaptá-los à freqüência padrão usada na maioria das placas para compatibilidade USB ao usar a série AT91SAM7S. Se você usar outro alvo e ele não funciona para você apenas remover as linhas começando com mww. Um exemplo para um programa-alvo (make programa) no makefile. O exemplo é um pequeno programa para um AT91SAM7S64 ou AT91SAM7S256 em um Atmel AT91SAM7-EK ou OX SAM7-EK avaliação da placa. Souce-code, linker-scripts, makefile e OpenOCD-config / - script estão incluídos. Download (zip, timestamp 20061013) Se os lockbits estiverem configurados (isto é, se o SAM-BA tiver sido usado antes) eles devem ser apagados com o comando flash proteger. Inicie o OpenOCD (consulte openocdgodebug. cmd no arquivo), conecte-se ao OpenOCD pelo telnet (telnet localhost 4444) e use o comando flash info 0 para determinar o número de lockbits (saída após lockbits: i. e. 16). Desproteger com o comando flash proteger 0 0 ltnumber of lockbits-1gt off (isto é, flash proteger 0 0 15 off). O apagamento manual do flash deve ser feito para o flash completo. Utilize o comando flash erase 0 0 ltnumber de secções-1gt (ou seja, flash erase 0 0 15). Usualy não é necessário para apagar manualmente desde o SAM7 flash-programação-funções em OpenOCD já fazer isso automaticamente durante a gravação flash. Para aqueles que usam um controlador AT91SAM7X: Eu tenho um e-mail de David Jander:. O AT91SAM7X introduziu a seleção de bootloader via NVM-bits em flash. Uma parte vazia (ou apagada usando o pino ERASE), irá programar bem com OpenOCD usando suas instruções (ajustando os bits óbvios para SAM7X), mas o aplicativo nunca será executado Isso é porque NVM-bit2 (seleção de inicialização) tem A ser definido. AFAIK isso só pode ser feito usando o SAM-BA (a ferramenta proprietária ATMEL) agora, já que OpenOCD não suporta bits NVM ainda (por favor me corrija se eu estiver errado. David não se enganou quando escreveu seu e-mail. Mas a situação mudou entretanto. Versões posteriores do OpenOCD oferecem um comando para definir / limpar NVM-bits. Isto foi confirmado por Uwe Bonnes para o SVN-Versão 90 / 31.8.2006. O comando é at91sam7 gpnvm ltnum ltbitgt ltsetcleargt em que ltnumgt é o número do flash-bank conforme indicado no arquivo de configuração, ltbitgt e ltsetcleargt é óbvio. Exemplo: at91sam7 gpnvm 0 2 set. Verifique o estado dos gpnvm-bits após um apagamento manual do flash. Escrever ST STR71x memória flash interna A abordagem básica é a mesma já apresentada para os outros alvos. O arquivo de configuração - aqui para um dispositivo baseado em FT2232 conectado a um STR710: Você pode ter que desproteger o flash usando o comando flash proteger através da interface telnet uma vez. Por favor, leia o Flash-Programming Application-Note disponível a partir de st Atualmente eu apenas fornecer um pequeno exemplo-pacote com demonstra como o flash interno de um STR710 pode ser programado usando OpenOCD. Você pode baixar o pacote de demonstração, incluindo a configuração do OpenOCD, o script de programação e um pequeno exemplo de aplicativo aqui. O método foi testado com a placa de avaliação ST STR710. Programação de memórias flash externas CFI O OpenOCD também suporta a programação de memórias flash externas. O exemplo a seguir foi criado para um controlador STMicro STR710 e foi testado com a memória flash externa ST M28W320B (4Mbytes) como na placa de avaliação STR710. Mas a abordagem é bastante geral e deve ser facilmente transportável para outros alvos. Iniciar openocdstartflashcfi. cmd primeiro executará openocdsetup. cmd para ler na configuração geral (OpenOCD install-path, interface usada etc.) e definir algumas variáveis ​​de ambiente. Essas variáveis ​​são usadas para determinar o parâmetro para openocd. exe que é chamado pelo openocdstartflashcfi. cmd também. Ambos os arquivos cmd são feitos para MS-Windows OS, mas podem ser facilmente portados para Unix / Linux shell-scripts. O OpenOCD iniciará e lerá o script openocdflashcfiftdi. cfg e, após a intaliação da interface JTAG, reiniciará o ARM alvo e processará os comandos listados no arquivo openocdflashcfi. script. O arquivo cfg está atualmente preparado para uma JTAGkey (ou compatível com o WinARM-JTAG), mas pode ser facilmente adaptado a outras interfaces baseadas em FTDI2232 ou interfaces de porta paralela (Wigglers) modificando a seção de interface no arquivo cfg. Exemplos nesta e em outras páginas podem servir como modelos. Download de um arquivo zip que inclui os arquivos cmd, cfg e script juntamente com um exemplo de código-fonte de aplicativo E sim, o método descrito pode ser usado para instalar o uClinux no STR710 eval-board (eu testei isso aqui ). O carregador de inicialização disponível na aplicação Code-Package para STs-nota AN2119 Introdução ao uClinux para STR71x pode ser carregado para o flash externo usando o OpenOCD. Crie o script de configuração e reset do OpenOCD na mosca Aqui uma abordagem para criar o script de configuração necessário e o script de reinicialização que incluem o comando de programação flash em tempo de execução em um makefile. O arquivo a seguir usa a sintaxe makefile. Basicamente é um makefile, mas é incluído no makefile de aplicativos. Eu escolhi esta aproximação desde que incluir tudo em um único makefile seria um pouco confuso. Este exemplo demonstra a configuração para piscar a memória flash interna de um STMicrosystems STR710, mas pode ser facilmente adaptado a outros alvos. O conteúdo do arquivo oocdflashing. mk: Como você pode ver tudo pode ser configurado neste arquivo. O programa-alvo nos projetos makefile se parece com isto: Um exemplo com todos os arquivos necessários pode ser encontrado aqui. STMicroelectronics STM32 Graças à biblioteca de destino incluída em versões posteriores do OpenOCD, não há necessidade de gravar arquivos de configuração e scripts próprios para a maioria das tarefas. Programar o flash interno de um STM32 é uma dessas tarefas, todas as configurações necessárias estão incluídas nos pacotes do OpenOCD (se não podem ser baixadas do OpenOCD SVN, veja o link abaixo). Um exemplo para programar as seções necessárias de um arquivo-elfo em um STM32F103VB usando um JTAGkey Amontec, verificar a imagem e executar o aplicativo: O arquivo jtagkey. cfg inclui os comandos de configuração para um JTAGkey Amontec se você estiver usando outra interface apenas substituir este . Consulte o diretório de interface para outras configurações prontas. O arquivo inclui todos os stettings necessários para a família STM32 (veja abaixo). O comando init inicializa OpenOCD Os destinos disponíveis / detectados são listados após o comando target (opcional) Os controladores precisam ser interrompidos antes da programação flash, isso é feito com o comando halt A programação do Flash é feita pelo comando flash writeimage. Uma vez que apagar se dado os sectores ocupados pela nova imagem de carga são apagados automaticamente antes da programação. O nome da carga-imagem segue. OpenOCD auto-detects the format, so if the load-image is in hex-format just give i. e. test. hex. Raw-binary format can also be used but the offset has to be given as parameter following the file-name (i. e.test. bin 0). The previously written image gets compared with the controllers memory-content with the verify-image command The controller get reseted and will run the newly loaded application after the reset run command Finally OpenOCD terminates itself after the shutdown command. This is the file jtagkey. cfg (OpenOCD SVN1586). Note that it is prepared for different boundary scan TAP IDs, so there is no need to specify one on your own as long as your STM32 has a ID listed in the file. This is the file stm32.cfg (OpenOCD SVN1586) This is how I have integrated the call of OpenOCD to implement a make program make-target: 196015 hits since April 24, 2006 Last mod. Sunday, 03-May-2009 02:32:58 CEST