Como você sabe, a compatibilidade com as ferramentas GNU e o suporte ao GDB tornam praticamente qualquer ambiente de desenvolvimento popular adequado para depurar uma ampla variedade de plataformas incorporadas, na maioria das vezes de forma gratuita e legal. Em teoria.
O que acontece na prática ao tentar fazer amizade com o STM32 e o NetBeans, e é possível, em princípio, obter um sistema viável com suporte para as últimas pedras - sob o corte.
Algumas letras
Eu realmente não queria deixar o microchip. No entanto, após a compra da Atmela, eles primeiro encobriram, talvez, uma das famílias mais promissoras do portfólio da empresa - PIC32MM e, em seguida, toda a linha MIPS. Tornou-se óbvio que, no futuro previsível, a transição para a ARM é inevitável, porque o microchip por dois anos não integra o suporte dos controladores Atmelovsk em seu ecossistema, não ofereceu nenhuma vantagem em “Fique conosco”. Pelo contrário, a política de preços em alta e as dificuldades organizacionais tradicionais da fusão tornaram os AWPs da Atmelovskiye menos atraentes. Ao mesmo tempo, apareceu um projeto que o PIC32MZ simplesmente encontrou. Uma massa crítica foi conquistada.
Por que STM: ampla cobertura de mercado, depuração de orçamento, um ambiente de código aberto gratuito e completo com base no SW4STM32 de código aberto, bem, o aspecto político - a ST Microelectronics é apoiada pelo governo francês como um recurso estratégico, portanto, a saída repentina do mercado ou aquisição, ao que parece, não é ameaçada.
Depuração - primeiras impressões
O SW4STM32 foi instalado da maneira tradicional - pressionando repetidamente o botão Avançar> (* a seguir, todos os experimentos ocorrem no Win7 x64). Um projeto de demonstração adequado para testar a função desejada foi removido do pacote STM32Cube Firmware, tudo funcionou mais ou menos imediatamente. O primeiro início do emulador JTAG deixou uma impressão: todo o ciclo de entrada no modo de depuração, começando na conexão e terminando com a parada no início de main (), com a atualização do contexto, pode acontecer em 1-2 segundos. Comparado aos depuradores de microchips (até o REAL ICE por meio meio), a diferença de velocidade é múltipla!
E, no entanto, algo desagradavelmente surpreendido.
O que há de errado com o Eclipse / SW4STM32
Uma infinidade de configurações e organização ilógica, itens de menu ocultos, perspectivas, bugs de interface e artefatos visuais, faltando teclas de atalho e funções usadas na barra de ferramentas, pequenos pictogramas e marcadores desajeitados e ilegíveis, a ausência de "Encontrar usos" é parcialmente subjetiva e você pode adaptar, se desejar . Mas: esquece regularmente de salvar os arquivos modificados antes da montagem, embora todas as marcas de verificação sejam necessárias; com economia manual forçada, ele não vê mudanças e a montagem incremental acaba sendo irrelevante; não há reconstrução completa (Limpeza e Construção) como uma única equipe e, após a limpeza forçada pelo Projeto Limpo, a montagem falha (acesso ao arquivo?) e é concluída com êxito somente após a quarta tentativa - isso não pode mais ser explicado de maneira razoável. Mesmo as primeiras versões do MPLAB X Beta baseadas no antigo NetBeans 6.xx não tiveram os mesmos problemas há 10 anos que o ambiente de desenvolvimento oficialmente suportado pelo STM32 atualmente.
Além disso, com o SW4STM32, 3 cópias de IDEs típicos já estão discadas no sistema, pois, além disso, ainda há MPLAB X firmemente pregado no NetBeans 8.0.1 e um pouco restrito (ou seja, é impossível usá-lo para outros idiomas / plataformas), e NetBeans 8.2 para Java e C / C ++.
Acontece que a configuração do NetBeans 8.2 para trabalhar com o STM32 eliminará os problemas práticos descritos no Eclipse, reduzirá o número de cópias IDE e reduzirá para uma plataforma, embora com versões ligeiramente diferentes.
Ferramentas NetBeans 8.2 e GNU ARM
O NetBeans é melhor usar 32 bits, porque além de duplicar o consumo de memória, não foi possível encontrar as diferenças da versão de 64 bits.
O Google encontrou rapidamente um
guia de configuração . A principal diferença estava apenas no sistema operacional (eles têm Linux contra o Win7 x64 para mim); portanto, a instalação do * nix-environment MSYS, incluído no pacote MinGW, tornou-se um jogo de premiação. As configurações da cadeia de ferramentas devem ser algo como isto:
Um ponto importante - ao adicionar a cadeia de ferramentas GNU ARM, selecione a família "GNU MinGW"; nesse caso, o NetBeans chamará corretamente o MSYS. Se o Cygwin já estiver instalado na máquina, será lógico usá-lo; portanto, a família GNU ARM deve selecionar “GNU Cygwin”.
Conseguir uma compilação bem-sucedida não foi fácil, mas muito simples. Como o SW4STM32 usa o mesmo compilador, observando a linha de comando da chamada do compilador no SW4STM32 e copiando as chaves ausentes em Propriedades do projeto → Compilador C → Opções adicionais
obtemos exatamente o mesmo resultado de saída, mas com uma importante diferença prática - tudo é coletado na primeira vez, há o Clean and Build e funciona bem:
Mas esse resultado também pode ser aprimorado adicionando o processamento pós-compilação opcional. Abra o Makefile e, na seção .build-post: .build-impl add:
.build-post: .build-impl cp ${CND_DISTDIR}/${CONF}/${CND_ARTIFACT_NAME_${CONF}} ${CND_ARTIFACT_NAME_${CONF}} arm-none-eabi-objcopy -O ihex ${CND_ARTIFACT_NAME_${CONF}} ${CND_ARTIFACT_NAME_${CONF}}.hex arm-none-eabi-size ${CND_ARTIFACT_NAME_${CONF}}
(importante - o recuo deve ser um caractere de tabulação único, não espaços)
Linha por linha: 1 - copia o arquivo do objeto (.elf) da pasta de saída para a raiz do projeto, para facilitar o acesso; 2 - gera HEX do elf (pode ser comentado se HEX não for necessário); 3 - exibe a quantidade de memória ocupada por segmentos.
O resultado final:
Até agora tudo bem.
OpenOCD - as primeiras dificuldades
Nos manuais online mencionados acima, a programação de um chip através do OpenOCD é simples e rotineira. A versão mais recente (0.10.0) é instalada, o arquivo de configuração é obtido (do kit OpenOCD ou da pasta do projeto SW4STM32), e um comando do formulário é escrito em Propriedades do Projeto → Executar:
e tudo funciona imediatamente. Na verdade, esse é o caso de famílias mais jovens, como STM32F103 e F407, mas estou interessado em F7 e H7. Com o primeiro, a versão oficial do OpenOCD 0.10.0 falha com os erros "falha de auto_probe" e "motivo de depuração indefinido 7"; estes últimos não são suportados. Tentamos todas as assembléias oficiais disponíveis 0.10.0 de janeiro de 2017 e janeiro de 2018 - o resultado é idêntico. Uma pesquisa por palavra-chave confirma a existência do problema, embora você não possa nomeá-lo em massa; não há análise e solução.
Mas há uma versão que é garantida para o trabalho - a partir do kit SW4STM32. Naturalmente, acaba sendo aprimorado e complementado, com novos scripts e suporte para a família H7. Além disso, a estrutura do arquivo foi alterada e, no plug-in, os recursos são armazenados em um módulo separado; portanto, para que o utilitário consolidado em uma única pasta veja seus scripts, a opção -s era necessária.
Board.cfg para NUCLEO-F767ZI, líquido de comentários, e condensado:
set CHIPNAME STM32F767ZITx source [find interface/stlink-v2-1.cfg] transport select hla_swd source [find target/stm32f7x.cfg] set WORKAREASIZE 0x10000 set ENABLE_LOW_POWER 1 set STOP_WATCHDOG 1 reset_config srst_only srst_nogate connect_assert_srst set CONNECT_UNDER_RESET 1
Finalmente, inicie o projeto Main Run:
O firmware foi bem sucedido, o código está em execução.
Depuração
O esquema é considerado o mais tradicional: um servidor GDB local no OpenOCD, o NetBeans se conecta a ele através do host local: 3333 via TCP. Consequentemente, o NetBeans exigirá o plug-in Gdbserver.
É possível simplificar o lançamento do OpenOCD por meio de um script bat e, uma vez que após a conclusão da sessão, ela vai para o console, faz sentido repetir a reinicialização sem parar:
:start openocd -f debug.cfg -sd:/Prog/openocd/scripts goto start
Lançamento:
A versão do SW4STM32 não está escrita explicitamente, mas o servidor está aguardando uma conexão TCP na porta 3333. No NetBeans, selecione Depurar → Anexar Depurador ... e instale:
A sessão está ativa. Terminal OpenOCD:
Na aparência, tudo parece bom - a sessão de depuração está ativa, o código é executado. No entanto, o problema ainda existe.
O problema
No modo de execução livre, a execução não pode ser parada.
Se você definir um ponto de interrupção antes de iniciar a sessão, ao inserir a depuração, ele será interrompido com a atualização de contexto, a execução passo a passo e as variáveis de visualização / alteração funcionarão, ou seja, em princípio, todas as funções básicas necessárias para a depuração completa:
Mas apenas até o próximo início gratuito, após o qual resta apenas fechar e reiniciar a sessão.
Outro pouco desagradável está associado aos pontos de interrupção do software: a função SYSTEM_Halt () é definida como __asm__ ("bkpt"), e sua operação leva à exibição de um diálogo desnecessário:
Quando você clica em Descartar e Pausar, ele funciona conforme necessário (ou seja, interrompe a execução), no entanto, é impossível definir essa opção por padrão e desativar a exibição da janela por meios padrão.
Antes da pilha, eu gostaria de automatizar o lançamento do OpenOCD e conectar o depurador diretamente através do NetBeans.
No entanto, objetivamente, a única função que não é suficiente para depuração mais ou menos completa é interromper a execução (também é necessário definir um ponto de interrupção em tempo real).
Depuração de depuração
Uma pesquisa no google revelou que problemas semelhantes com o NetBeans parando o GDB pararam, mas foram corrigidos há vários anos. Por falta de uma idéia melhor, as fontes do NetBeans foram baixadas na esperança de percorrer o depurador ao vivo. Surpreendentemente, conseguimos localizar rapidamente o problema antes de chamar o utilitário externo GdbKillProc.exe, que é essencialmente um invólucro para DebugBreakProcess (pid) do WinAPI. O princípio do utilitário é reduzido a uma interrupção não invasiva do processo (análogo de "kill -SIGINT [pid]" sob * nix ou Ctrl + C no console).
Mas ela não trabalha.
O que é testado
No modo de console, o cliente GDB (arm-none-eabi-gdb.exe) reage corretamente ao Ctrl + C, ou seja, interrompe a execução do código sem fechar a sessão e aguarda mais instruções.
O ps -W e o Windows Process Explorer exibem o processo corretamente e o PID corresponde à variável interna no NetBeans.
A chamada manual "kill -SIGINT [pid]" do pacote MSYS gera um erro "No such process".
A verificação de "taskkill / pid [pid]" produz "O processo ... não pôde ser encerrado ... Este processo pode ser encerrado apenas com força ...", o que parece indicar um bloqueio do sistema. Com a opção / f, o processo fecha completamente, o que também não é bom.
No processo, verificou-se que, no Windows, a situação com a geração de sinais de interrupção não importa, ou melhor, de maneira alguma: apenas o analógico SIGTERM é suportado por padrão, o que corresponde a uma redução aproximada do processo, e não existe uma solução geralmente aceita.
Na Internet, foi encontrado um utilitário windows-kill, projetado para emular Ctrl + C e Ctrl + Brk. O processo descobre que a interrupção é enviada sem erros, mas o cliente GDB ainda não responde.
Os experimentos foram realizados usando todas as versões de 32 bits (NetBeans, ARM Tools, MSYS 1.0), exceto o windows-kill, que se recusou a iniciar 32 bits ("... não foi possível iniciar corretamente ..."). Talvez o problema seja justamente isso, porque, de acordo com dados fragmentados de fóruns e rastreadores de erros, a profundidade de bits do utilitário e do processo deve coincidir. A dificuldade aqui é que o ARM não oferece a versão x64 da cadeia de ferramentas para Windows, incluindo a única maneira de eliminar a heterogeneidade é fazer a versão x32 do windows-kill funcionar, o que também não está claro se o Win x64 é possível em princípio.
No meio do processo, o sistema operacional foi reinstalado do zero e nenhuma alteração no comportamento dos sujeitos experimentais foi notada, incluindo com grande confiança que os recursos de um sistema específico podem ser eliminados.
Assistência no salão necessária
Na verdade, todos os itens acima podem ser considerados uma introdução a este parágrafo.
O último passo é tornar a depuração do STM32 no NetBeans real:
requer um mecanismo de software funcional para enviar o sinal de interrupção SIGINT (Ctrl + C) para o processo do cliente Windows GDBA seguir, é apresentada uma recomendação para definir a configuração mínima suficiente para verificar / depurar o problema acima. Se / quando ele puder ser resolvido, o artigo será refeito em um guia passo a passo simples sobre como configurar o NetBeans + OpenOCD para várias famílias diferentes e quadros de depuração. Outras funcionalidades podem ser concluídas à vontade, já tendo uma solução básica viável.
Configuração de teste
É proposto o uso da placa Blue Pill baseada no STM32F103C8T6 e no clone ST-Link V2 como plataforma de hardware.
É necessário:
1. Instale a
cadeia de ferramentas incorporada GNU Arm2. Instale o OpenOCD 0.10.0 (
compilado no Win )
3. Registre as pastas bin de ambos os pacotes no PATH (Painel de controle → Sistema → Configurações avançadas do sistema → Variáveis de ambiente ... → Caminho).
4. Em um local conveniente para criar o arquivo board.cfg, copie o conteúdo:
source [find interface/stlink-v2.cfg] source [find target/stm32f1x.cfg] transport select "hla_swd" reset_config none separate set WORKAREASIZE 0x5000 set CHIPNAME STM32F103C8T6 set ENABLE_LOW_POWER 1 set STOP_WATCHDOG 1 set CLOCK_FREQ 4000 set CONNECT_UNDER_RESET 1
5. Escolha o firmware de teste apropriado (test.elf), o principal critério é que a execução e a parada sejam claramente distinguíveis. Copie para um local conveniente.
6. Em um local conveniente para exibir o quadro:
openocd -f board.cfg -c "program test.elf verify reset exit"O firmware deve iniciar. Exemplo de saída do OpenOCD para o console:
7. Em um local conveniente para iniciar o servidor OpenOCD GDB:
openocd -f board.cfgO código ainda está em execução; saída de amostra (o console permanece bloqueado pelo OpenOCD):
8. Em outro console ou execute diretamente arm-none-eabi-gdb.exe no pacote GNU ARM Embedded Toolchain e execute os comandos:
target extended-remote localhost:3333 (código ainda em execução)
continue (o código está sendo executado, o console está bloqueado)
Ctrl+C (código parado, console ativo)
continue (executando novamente, o console está bloqueado)
A tarefa é remover o cliente GDB do estado de execução (ou seja, emular essencialmente Ctrl + C) programaticamente.
Para descobrir a identificação do processo, use "ps -W" no ambiente * nix ou Windows Process Explorer (instalado opcionalmente).
Talvez alguém depure corretamente após a configuração inicial do NetBeans - essas informações também serão úteis, especialmente com uma descrição detalhada do sistema e possíveis recursos.
Compartilhe idéias nos comentários e espero que, trabalhando juntos, possamos transformar um experimento ousado em um guia útil para configurar uma ferramenta ainda mais útil.