Aller au contenu

Filament ABS

stef_ladefense

bootloader Flash d’un BootLoader sur un Arduino en se servant du port ICSP...

Recommended Posts

Flash d’un BootLoader sur un Arduino en se servant du port ICSP et d’un autre Arduino transformé temporairement en interface de programmation.

 

J’ai reçu dernièrement une carte contrôleur de type Trigorilla (Anycubic) et impossible de la flasher, aussi bien avec un .hex qu’avec l’IDE Arduino et les sources de Marlin.

J’ai parlé de ce soucis dans la session Anycubic et @thsrp m’as posé la question de savoir pourquoi quand on demande à l’IDE Arduino d’exporter les binaires compilés, il générait deux fichiers .hex, un avec le BootLoader et un sans le BootLoader.

J’en profite donc pour vous expliquer ça et aussi pour détailler la procédure pour reflasher son BootLoader en utilisant le port ICSP présent sur nos cartes.

 

Ces deux fichiers sont donc destinés à flasher un Arduino sans avoir accès aux sources.

image.png.468b3a6dfa3933c50dc72919c4baa7f5.png

Il existe plusieurs solutions pour les utiliser :
- En USB (à travers une interface USB/RS232) via Cura, Repetier, …
- Via le port ICSP à 6 broches avec une interface spécifique.
- Et même en WIFI sur des microcontrôleurs équipés type ESP8266 ou ESP32.

 

La solution de flasher en USB :

- soit directement depuis l’IDE Arduino quand on compile les sources (de Marlin par exemple),
- ou via Cura, Repetier (ou autres) quand on ne possède que le .hex,
nécessite que le BootLoader (BL) de la carte fonctionne correctement et communique avec l’hôte qui envoi les données que le BL écrit dans sa mémoire flash.

Donc le cas classique : nous avons par exemple un ATmega2560, avec son BL, branché en USB :

Dans cette configuration, peu importe que le .hex ne contienne ou pas le BL, cela fonctionne dans les deux cas, car l’algorithme de transfert du BL ne prends que le programme dans le .hex et jamais le BL interne de l’ATmega ne sera effacé ou remplacé. Ce qui nous arrange bien en fait, pas besoin de se soucier d’avoir un .hex avec ou sans BL.

 

Alors pourquoi générer les deux ?

Il existe une autre façon de flasher un ATmega, c’est le fameux port ICSP à 6 broches !

Par exemple sur le composant ATmega neuf, en sortie de chaine de fabrication, il est complètement vide, pas de programme d’amorçage (BL).
Hors une carte Arduino par exemple, doit pouvoir être programmé en USB directement, donc on lui implante un BL via ce fameux port ICSP.

Un autre exemple, une carte industriel sur laquelle on injecte son firmware via ICSP, si cette carte ne possède pas de port de programmation série, pas besoin de lui charger un BL, la maintenance se fera via ICSP si besoin.

Dans le cas où une carte est livrée avec un port de programmation (série ou USB) et en plus avec ses sources (une carte pour piloter une imprimante par hasard), dans ce cas son firmware devra comporter aussi son BL pour que les futurs flashs en USB puissent se faire.

En production, l’utilisation de l’ICSP est essentiel pour des raisons de vitesses, pas besoin de compiler à chaque fois la source pour l’implanter. Ce protocole est le SPI.

Sur nos cartes Arduino, il se présente sous la forme de 6 picots en 2x3 avec un repère en broche 1.

image.png.c10ee962984160c7cb131c75fbd4b526.png

Broche 1 : MISO    Broche 2 : VCC 5V (ou 3.3V en fonction des cartes)
Broche 3 : SCK (Clock)    Broche 4 : MOSI
Broche 5 : RESET    Broche 6 : GND (masse, 0V)

 

L’utilisation que l’on peut en faire ici, c’est surtout de flasher un BootLoader.

Et ça peut être bien utile dans plusieurs cas :

Un ATmega vierge (sans BL donc), ou une mise à jour par exemple aux Nano du soleil levant qui sont livré avec le vieux BL, il est intéressant de le mettre à jours pour Optiboot 6.2 par exemple, surtout que c’est maintenant le BL officiel des UNO depuis quelques temps chez Arduino.

Mais il peut arriver aussi qu’un programme fasse planter tellement profondément le microcontrôleur que son BL ne puisse plus répondre aux commandes de flash et dans ce cas-là, impossible d’utiliser la connexion USB.

La seule solution c’est d’utiliser le port ICSP et de graver sa séquence d’initialisation qui efface la mémoire du composant et lui réinjecte son BL.

Pour faire cette manipulation, il suffit d’avoir sous la main un autre Arduino, Uno, Nano, Mega peu importe si ils fonctionnent sous la même tension, ici 5V et avoir quelques fils Dupont pour brancher le tout.


Pour la partie software, tout est déjà présent dans l’IDE Arduino.

 

Mise en œuvre :

Dans un premier temps, on va injecter un programme pour communiquer avec le port ICSP à l’Arduino qui va nous servir d’interface : ArduinoISP.

1) Dans l’IDE, on commence donc par connecter « l’Arduino Interface » et de choisir son modèle (ici un Uno pour l’exemple) et son port COM dans le menu Outils.

image.png.d5c081f53aa1e7701f457b2a69f7af4d.png


2) On ouvre Fichier, Exemples, ArduinoISP.

image.png.ad84b681ec3557e5befffcf95f715719.png

 

3) On téléverse (beurk) (CTRL+U) ce fichier dans « l’Arduino Interface ».

Nous avons alors notre « Arduino Interface » programmé avec un émulateur de programmateur ICSP, qu’il faut maintenant relier à la carte cible sur laquelle nous voulons réécrire le BL.

Déjà on débranche l’USB, autant éviter les courts circuits. La carte cible n’est pas non plus alimentée !

On va relier les deux connecteurs ICSP de cette manière à l’aide de 5 câbles Dupont :

image.png.33d2c7fc1a37af1147f43e6c2c7214c3.png

Rien de plus simple, VCC sur VCC, GND sur GND, MISO sur MISO, MOSI sur MOSI et SCK sur SCK.

Le 6eme câble est sur la broche RESET de la cible,

Et la broche RESET de la cible ne doit en aucun cas être reliée à la broche RESET de l’Arduino servant d’interface !!!

Cette broche sera reliée au connecteur D10 sur la Uno ou Nano (ou D53 si il s’agit d’un ATmega 2560 ou 1280).

image.png.2f9f0e08d9bd5e6d9b1da49f83da24b9.png

A partir de ce câblage, en aucun cas l’Arduino cible ne devra être alimenté sur son port USB ou Jack d’alimentation !  C’est « l’Arduino Interface » qui alimente la cible !

 

Nous allons pouvoir « graver la séquence d’initialisation ».

Brancher l’USB de « l’Arduino Interface » sur l’ordinateur.

Dans l’IDE, choisir le modèle d’Arduino CIBLE (dans l’exemple ici un ATmega2560).

Choisir le port COM de « l’Arduino interface ». C’est lui qui est branché en USB sur l’ordinateur !

Et choisir dans Outils / Programmateur : Arduino as ISP

image.png.5edaffee8dac8693405c223c4ccc9d0d.png

 

Il suffit ensuite de lancer « Graver la séquence d’initialisation »

image.png.fbb08a9710edddc89d7e08384b3288f5.png

Et en quelques secondes, la cible sera effacée et son BL flashé.

image.png.1cb2d3e98169d71d178f399f689e2b50.png

 

Il suffit maintenant de débrancher l’USB, les 6 câbles Dupont qui sont sur son port ICSP.

L’ATmega est maintenant vierge et possède son BL.

Il est maintenant flashable en USB par les moyens conventionnels.

 

Voilà !

 

Personnellement je me suis fait cette interface à partir d’un Nano, normalement il est enrobé de gaine thermo mais pour la photo je l’ai retirée.

image.png.4c647144374338eb072a384d5050b04e.png

Pour ceux qui se posent la question, la broche 1 est en bas à gauche sur ce nano.

J’ai retiré le contact 5 (RESET) dans le connecteur 6 points et laisser son câble plus long pour le connecter sur D10. (Car je le répète, les deux RESET ne doivent pas être reliés entre eux !).

Le même in situ pour flasher le BL d’une carte Trigorilla livré sans (merci soleil levant).

image.thumb.png.fff837c9da88ee934d606b1683bdaeb1.png

Le liseré rouge dans mon cas est coté broche 1 sur les connecteurs ICSP.

 

On peut aussi acheter sur eBay pour moins de 10 euros, un programmateur compatible de ce style, ce qui peux être pratique quand on a pas d’Arduino sous la main.

image.png.3d6c4cbcee834a0b03387914daa46700.png

Il suffit de le déclarer non plus en « Arduino as ISP » mais en « USBasp », la procédure reste la même.

 

Stef_ladefense

Modifié (le) par stef_ladefense
corrections
  • J'aime 2
  • Merci ! 4

Partager ce message


Lien à poster
Partager sur d’autres sites

@stef_ladefense

Joli tuto simple à comprendre....et comme déjà dit clair et précis

En revanche tu n'as pas répondu a ma question quand on "compile les binaries" on obtient deux fichiers le .hex et le withbootloader.hex     Le premier tout le monde c'est ce que c'est ,je m'en suis d'ailleurs servi plusieurs fois pour flasher la Trigo sans passer par la fonction "televersement" mais pourquoi ce deuxième .hex ??? car si pas de bootloader sur la carte ce n'est pas qu'avec ce fichier que cela fonctionnera par liaison classique USB

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 3 heures, thsrp a dit :

@stef_ladefense

En revanche tu n'as pas répondu a ma question quand on "compile les binaries" on obtient deux fichiers le .hex et le withbootloader.hex     Le premier tout le monde c'est ce que c'est ,je m'en suis d'ailleurs servi plusieurs fois pour flasher la Trigo sans passer par la fonction "televersement"

si si !

Il y a 3 heures, thsrp a dit :

mais pourquoi ce deuxième .hex ??? car si pas de bootloader sur la carte ce n'est pas qu'avec ce fichier que cela fonctionnera par liaison classique USB

non effectivement, si tu n'as pas de BL sur la carte, de toute façon tu ne pourras pas passer par la liaison série, donc soit tu remets un BL via ICSP et apres tu flash le .hex

ou tu flash directement le .hex contenant le BL en ICSP avec Avrdude en ligne de commande, et tu auras le BL + le programme d'un coup

Il y a 11 heures, stef_ladefense a dit :

Alors pourquoi générer les deux ?

.....

Un autre exemple, une carte industriel sur laquelle on injecte son firmware via ICSP, si cette carte ne possède pas de port de programmation série, pas besoin de lui charger un BL, la maintenance se fera via ICSP si besoin.

pas de port serie sur la carte, (donc pas de port usb puisque ce n'est qu'un pont usb<>rs232) donc l'utilisateur final n'as pas à y toucher, pas la peine d'utiliser un BL, donc on prends le .hex de base et en plus on gagne de la place sans prendre le risque de bidouille facile (je dis facile car l'icsp est toujours disponible)

Il y a 11 heures, stef_ladefense a dit :

Dans le cas où une carte est livrée avec un port de programmation (série ou USB) et en plus avec ses sources (une carte pour piloter une imprimante par hasard), dans ce cas son firmware devra comporter aussi son BL pour que les futurs flashs en USB puissent se faire.

là effectivement on flash en ICSP le .hex qui contient le BL (nous somme en phase industriel donc en ICSP, pas à la maison avec nos outils simples en USB!)

il existe même un autre cas, c'est un code si volumineux qu'il ne rentre plus à cause du bootloader, dans ce cas on flash en icsp pour économisez la taille du BL, qui peut prendre  de 512 octets pour les plus petits jusqu’à 8ko pour le 2560 (8ko sur 256ko)

mais il ne faut pas oublier que l'Arduino ne se resume pas qu'a faire fonctionner Marlin, et que derrière c'est le compilateur Atmel (le fabriquant des ATmega en autre) et que ce compilo génère les deux types de fichiers, en tout cas c'est comme ça et ça ne m’empêche pas de dormir :).

maintenant j'aurais trouvé plus logique que l'on puisse choisir à ce moment la possibilité ou non de générer le binaire avec ou sans BL.
surtout dans l’environnement Arduino où personne n'utilise (ou presque) Avrdude (voir ici pour découvrir la chose !)

Partager ce message


Lien à poster
Partager sur d’autres sites

Bon, ben voilà j'ai compris !!!

Ce deuxième fichier hex compilé par IDE arduino ne peux pas nous servir a grand chose avec nos liaisons série/usb ...

Merci c'est plus clair , j'ai encore appris quelque chose...!!

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant


×