Comme vous le savez, la compatibilité avec les outils GNU et la prise en charge de GDB rendent presque tous les environnements de développement populaires adaptés au débogage d'une large gamme de plates-formes intégrées, le plus souvent gratuitement et légalement. En théorie.
Que se passe-t-il dans la pratique lorsque vous essayez de vous faire des amis avec STM32 et NetBeans, et est-il possible, en principe, d'obtenir un système viable avec le support des dernières pierres - sous la coupe.
Quelques paroles
Je ne voulais vraiment pas quitter la puce. Cependant, après l'achat par Atmela, ils ont d'abord couvert, peut-être, l'une des familles les plus prometteuses du portefeuille de l'entreprise - PIC32MM, puis toute la gamme MIPS. Il est devenu évident que dans un avenir prévisible, la transition vers l'ARM est inévitable, puisque la puce électronique depuis deux ans n'a pas intégré le support des contrôleurs d'Atmelovsk dans son écosystème, elle n'a pas donné d'avantages à «Rester avec nous». Au contraire, la politique de prix à la hausse et les difficultés organisationnelles traditionnelles de la fusion ont rendu Atmelovskiye AWP moins attractifs. Dans le même temps, un projet est apparu sur lequel le PIC32MZ est simplement tombé. Une masse critique a été acquise.
Pourquoi STM: large couverture du marché, débogage budgétaire, un environnement open source complet et gratuit basé sur l'open source SW4STM32, eh bien, l'aspect politique - ST Microelectronics est soutenu par le gouvernement français en tant que ressource stratégique, donc une sortie soudaine du marché ou une prise de contrôle ne semble pas menacée.
Débogage - Premières impressions
SW4STM32 a été installé de manière traditionnelle - en appuyant plusieurs fois sur le bouton Suivant> (* ci-après, toutes les expériences ont lieu sur Win7 x64). Un projet de démonstration adapté pour tester la fonction souhaitée a été supprimé du package du micrologiciel STM32Cube, tout fonctionnait plus ou moins dès la sortie de la boîte. Le premier démarrage de l'émulateur JTAG a laissé une impression: tout le cycle d'entrée en mode débogage, à partir de la connexion et se terminant par l'arrêt au début de main () avec la mise à jour du contexte, il s'avère, peut tenir en 1 à 2 secondes. Par rapport aux débogueurs à micropuce (même REAL ICE pour une demi-moitié), la différence de vitesse est multiple!
Et pourtant, quelque chose de désagréablement surpris.
Quel est le problème avec Eclipse / SW4STM32
Une myriade de paramètres et une organisation illogique, des éléments de menu cachés, des perspectives, des bogues d'interface et des artefacts visuels, des boutons et fonctions chauds manquants sur la barre d'outils, de petits pictogrammes et marqueurs maladroits et illisibles, l'absence de "Find Usages" est en partie subjective, et vous pouvez vous adapter si vous le souhaitez . Mais: oublie régulièrement de sauvegarder les fichiers modifiés avant l'assemblage, bien que toutes les coches soient nécessaires; avec une sauvegarde manuelle forcée, il ne voit pas de changements, et l'assemblage incrémental s'avère non pertinent; il n'y a pas de reconstruction complète (Clean and Build) en tant que commande unique, et après un nettoyage forcé via Clean Project, l'assembly échoue (accès aux fichiers?) et ne se termine avec succès qu'après la 4e tentative - cela ne peut plus être raisonnablement expliqué. Même les premières versions de MPLAB X Beta basées sur l'ancienne NetBeans 6.xx n'avaient pas les mêmes problèmes il y a 10 ans que l'environnement de développement officiellement supporté pour STM32 aujourd'hui.
De plus, avec SW4STM32, 3 copies d'IDE typiques sont déjà composées dans le système, car à côté de cela, il y a encore MPLAB X fermement cloué sur NetBeans 8.0.1 et quelque peu clôturé (c'est-à-dire qu'il est impossible de l'utiliser pour d'autres langues / plates-formes), et NetBeans 8.2 pour Java et C / C ++.
Il s'avère que la configuration de NetBeans 8.2 pour fonctionner avec STM32 éliminera les problèmes pratiques décrits d'Eclipse, réduira le nombre de copies IDE et le réduira à une seule plate-forme, bien que des versions légèrement différentes.
Outils NetBeans 8.2 et GNU ARM
NetBeans est préférable d'utiliser 32 bits, car en plus de doubler la consommation de mémoire, les différences de la version 64 bits sont introuvables.
Google a rapidement trouvé un
guide de configuration . La différence fondamentale était uniquement dans le système d'exploitation (ils ont Linux contre Win7 x64 pour moi), donc l'installation de l'environnement * nix MSYS, qui fait partie du package MinGW, est devenue un jeu de prix. Les paramètres de la chaîne d'outils devraient ressembler à ceci:
Un point important - lors de l'ajout de la chaîne d'outils GNU ARM, sélectionnez la famille «GNU MinGW», auquel cas NetBeans appellera correctement MSYS. Si Cygwin est déjà installé sur la machine, il sera logique de l'utiliser, en conséquence, la famille GNU ARM devrait sélectionner «GNU Cygwin».
Réaliser une compilation réussie n'a pas été facile, mais très simple. Puisque SW4STM32 utilise le même compilateur, en regardant la ligne de commande de l'appel du compilateur dans SW4STM32 et en copiant les clés manquantes dans Propriétés du projet → Compilateur C → Options supplémentaires
nous obtenons exactement le même résultat de sortie, mais avec une différence pratique importante - tout est collecté la première fois, il y a Clean and Build et cela fonctionne très bien:
Mais ce résultat peut également être amélioré en ajoutant le traitement post-construction facultatif. Ouvrez le Makefile et dans la section .build-post: .build-impl ajoutez:
.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}}
(important - le retrait doit être un caractère de tabulation unique, pas des espaces)
Ligne par ligne: 1 - copie le fichier objet (.elf) du dossier de sortie à la racine du projet, pour un accès plus facile; 2 - génère HEX à partir d'elfe (peut être commenté si HEX n'est pas nécessaire); 3 - affiche la quantité de mémoire occupée par segments.
Le résultat final:
Jusqu'ici tout va bien.
OpenOCD - les premières difficultés
Dans les manuels en ligne mentionnés ci-dessus, la programmation d'une puce via OpenOCD est simple et routinière. La dernière version (0.10.0) est installée, le fichier de configuration est extrait (du kit OpenOCD ou du dossier de projet SW4STM32), une commande du formulaire est écrite dans Propriétés du projet → Exécuter:
et tout fonctionne tout de suite. En effet, c'est le cas pour les familles plus jeunes telles que STM32F103 et F407, mais je suis intéressé par F7 et H7. Avec la première, la version officielle d'OpenOCD 0.10.0 se bloque avec les erreurs "auto_probe failed" et "undefined debug reason 7"; ces derniers ne sont pas du tout pris en charge. Nous avons essayé tous les assemblages officiels disponibles 0.10.0 de janvier 2017 et janvier 2018 - le résultat est identique. Une recherche par mot-clé confirme l'existence du problème, bien que vous ne puissiez pas le nommer massif; il n'y a pas d'analyse et de solution.
Mais il existe une version qui est garantie de fonctionner - à partir du kit SW4STM32. Naturellement, il s'avère être amélioré et complété, avec de nouveaux scripts et un support pour la famille H7. De plus, la structure des fichiers a été modifiée et les ressources sont stockées dans un module distinct dans le plug-in.Par conséquent, pour que l'utilitaire consolidé dans un seul dossier puisse voir ses scripts, le commutateur -s était requis.
Board.cfg pour NUCLEO-F767ZI, net des commentaires, et condensé:
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
Enfin, lancez via Run Main Project:
Le firmware est réussi, le code est en cours d'exécution.
Débogage
Le schéma est supposé être le plus traditionnel: un serveur GDB local sur OpenOCD, NetBeans s'y connecte via localhost: 3333 via TCP. En conséquence, NetBeans aura besoin du plugin Gdbserver.
Il est possible de simplifier le lancement d'OpenOCD via un script bat, et puisqu'une fois la session terminée, elle va à la console, il est logique de boucler le redémarrage à l'infini:
:start openocd -f debug.cfg -sd:/Prog/openocd/scripts goto start
Lancement:
La version de SW4STM32 n'est pas écrite explicitement, mais le serveur attend une connexion TCP au port 3333. Dans NetBeans, sélectionnez Debug → Attach Debugger ..., et installez:
La session est active. Terminal OpenOCD:
En apparence, tout semble bien - la session de débogage est active, le code est exécuté. Cependant, le problème existe toujours.
Le problème
En mode d'exécution libre, l'exécution ne peut pas être arrêtée.
Si vous définissez un point d'arrêt avant de démarrer la session, lorsque vous entrez le débogage, il s'arrêtera avec la mise à jour du contexte, l'exécution pas à pas et la visualisation / modification des variables fonctionneront, c'est-à-dire, en principe, toutes les fonctions de base nécessaires au débogage complet:
Mais seulement jusqu'au prochain démarrage libre, après quoi il ne reste plus qu'à fermer et redémarrer la session.
Une autre bagatelle désagréable est associée aux points d'arrêt logiciels: la fonction SYSTEM_Halt () est définie comme __asm__ ("bkpt"), et son fonctionnement conduit à l'affichage d'une boîte de dialogue inutile:
Lorsque vous cliquez sur Ignorer et suspendre, cela fonctionne comme requis (c'est-à-dire qu'il arrête l'exécution), cependant, il est impossible de définir cette option par défaut et de désactiver l'affichage de la fenêtre par des moyens standard.
Avant le tas, je voudrais automatiser le lancement d'OpenOCD et connecter le débogueur directement via NetBeans.
Cependant, objectivement, la seule fonction qui ne suffit pas pour un débogage plus ou moins complet est d'arrêter l'exécution (il est également nécessaire de définir un point d'arrêt à la volée).
Debug Debugging
Une recherche sur Google a révélé que des problèmes similaires avec NetBeans arrêtant GDB se sont arrêtés, mais ont été corrigés il y a plusieurs années. Faute d'une meilleure idée, les sources de NetBeans ont été téléchargées dans l'espoir de parcourir le débogueur en direct. Étonnamment, nous avons pu localiser rapidement le problème avant d'appeler l'utilitaire externe GdbKillProc.exe, qui est essentiellement un wrapper pour DebugBreakProcess (pid) à partir de WinAPI. Le principe de l'utilitaire se réduit à une interruption non intrusive du processus (analogue de «kill -SIGINT [pid]» sous * nix, ou Ctrl + C dans la console).
Mais elle ne travaille pas.
Ce qui est testé
En mode console, le client GDB (arm-none-eabi-gdb.exe) réagit correctement à Ctrl + C, c'est-à-dire qu'il arrête l'exécution du code sans fermer la session et attend d'autres instructions.
ps -W et Windows Process Explorer affichent correctement le processus et le PID correspond à la variable interne dans NetBeans.
L'appel manuel «kill -SIGINT [pid]» du package MSYS génère une erreur «Aucun processus de ce type».
La vérification via "taskkill / pid [pid]" donne "Le processus ... n'a pas pu être interrompu ... Ce processus ne peut être interrompu que de force ...", ce qui semble indiquer un verrouillage du système. Avec le commutateur / f, le processus se ferme complètement, ce qui n'est pas bon non plus.
Dans le processus, il s'est avéré que dans Windows, la situation avec la génération de signaux d'interruption n'a pas d'importance, ou plutôt pas du tout: seul l'analogue SIGTERM est pris en charge par défaut, ce qui correspond à une réduction approximative du processus, et il n'y a pas de solution généralement acceptée.
Sur Internet, un utilitaire de suppression de fenêtres a été trouvé, conçu pour émuler Ctrl + C et Ctrl + Brk. Le processus trouve que l'interruption envoie sans erreur, mais le client GDB ne répond toujours pas.
Les expériences ont été réalisées en utilisant toutes les versions 32 bits (NetBeans, ARM Tools, MSYS 1.0), à l'exception de windows-kill, qui refusait de démarrer 32 bits ("... impossible de démarrer correctement ..."). Peut-être que le problème est précisément cela, car, selon les données fragmentaires des forums et des bugtrackers, la profondeur de bits de l'utilitaire et du processus devrait coïncider. La difficulté ici est que ARM n'offre pas la version x64 de la chaîne d'outils pour Windows, y compris le seul moyen d'éliminer l'hétérogénéité est de faire fonctionner la version x32 de windows-kill, ce qui n'est pas clair si Win x64 est possible en principe.
Au milieu du processus, l'OS a été réinstallé à partir de zéro, et aucun changement dans le comportement des sujets expérimentaux n'a été remarqué, y compris avec une grande confiance les caractéristiques d'un système particulier peuvent être éliminées.
Aide au hall requise
En fait, tout ce qui précède peut être considéré comme une introduction à ce paragraphe.
La dernière étape restante consiste à rendre le débogage STM32 sous NetBeans réel:
nécessite un mécanisme logiciel fonctionnel pour envoyer le signal d'interruption SIGINT (Ctrl + C) au processus client Windows GDBCe qui suit est une recommandation pour définir la configuration minimale suffisante pour vérifier / déboguer le problème ci-dessus. Si / quand il peut être résolu, l'article sera refait dans un simple guide étape par étape sur la façon de configurer NetBeans + OpenOCD pour plusieurs familles et cartes de débogage différentes. D'autres fonctionnalités peuvent être complétées à volonté, ayant déjà une solution de base réalisable.
Configuration de test
Il est proposé d'utiliser la carte Blue Pill basée sur le STM32F103C8T6 et le clone ST-Link V2 comme plate-forme matérielle.
Il faut:
1. Installez la
chaîne d'outils intégrée GNU Arm2. Installez OpenOCD 0.10.0 (
build sous Win )
3. Enregistrez les dossiers bin des deux packages dans PATH (Panneau de configuration → Système → Paramètres système avancés → Variables d'environnement ... → Chemin).
4. Dans un endroit pratique pour créer le fichier board.cfg, copiez le contenu:
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. Choisissez le firmware de test approprié (test.elf), le critère principal est que l'exécution et l'arrêt sont clairement distinguables. Copiez dans un endroit pratique.
6. D'un endroit pratique pour flasher le tableau:
openocd -f board.cfg -c "program test.elf verify reset exit"Le firmware devrait démarrer. Exemple de sortie d'OpenOCD sur la console:
7. À partir d'un endroit pratique pour démarrer le serveur OpenOCD GDB:
openocd -f board.cfgLe code est toujours en cours d'exécution; exemple de sortie (la console reste verrouillée par OpenOCD):
8. Dans une autre console ou exécutez directement arm-none-eabi-gdb.exe à partir du package GNU ARM Embedded Toolchain et exécutez les commandes:
target extended-remote localhost:3333 (le code est toujours en cours d'exécution)
continue (le code est en cours d'exécution, la console est verrouillée)
Ctrl+C (code arrêté, console active)
continue (courir à nouveau, la console est verrouillée)
La tâche consiste à supprimer le client GDB de l'état d'exécution (c'est-à-dire essentiellement émuler Ctrl + C) par programme.
Pour connaître l'ID de processus, utilisez «ps -W» à partir de l'environnement * nix ou Windows Process Explorer (installé en option).
Peut-être que quelqu'un déboguera correctement juste après la configuration initiale de NetBeans - ces informations seront également utiles, en particulier avec une description détaillée du système et des fonctionnalités possibles.
Veuillez partager vos idées dans les commentaires, et j'espère qu'en travaillant ensemble, nous pourrons transformer une expérience audacieuse en un guide utile pour mettre en place un outil encore plus utile.