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.

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.

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.

2) On ouvre Fichier, Exemples, ArduinoISP.

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 :

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).

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

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

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

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.

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).

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.

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

Stef_ladefense

Bonjour,

Il y a 2 paramètre dans CURA dont j'ai du mal à comprendre à quoi cela correspond.

Le premier : Parfum G-CODE dans les paramètres de l'imprimante, ou l'on peut sélectionner entre autre MARLIN, REPETIER etc... Par curiosité, j'avais essayer MARLIN et REPETIER, mais j'ai constaté aucune différence sur un même print. J'ai pas trouvé d’explications détaillées sur les effets de ce paramètre : est-ce que quelqu'un aurait une idée ?

Le second : dans les paramètre d'impression, je ne comprends pas le paramètre "vitesse de rétraction primaire" et l'explication donné dans CURA : "Vitesse à laquelle le filament est préparé pendant une rétraction". Qu'est-ce qu'on entend par "préparé pendant une rétraction" ? Pareil, le manuel de CURA ne donne rien à ce sujet.

Est-ce que quelqu'un pourrais m'éclairer ?

Merci

Math

Il y a 4 heures, Locouarn a dit :

Pour ma part, ne modifiant rien aux fichiers de configuration, je voulais juste dire que la procédure de téléversement fonctionne parfaitement avec 1.1.9 (chez moi ).

ça évidemment, si t'as une A8 stock, aucun blème, par contre sur mon AM8, tout est à revoir.

@medmed assures toi d'uiliser le bon bootloader (arduino ne communiquera pas avec l'imprimante si tu sélectionnes Anet 1.0 alors que l'imprimante a l'optiboot, et vis et versa).
Assures toi aussi de fermer tout les autre logiciels communiquant avec l'imprimante, le ch340 n'écoute qu'un seul logiciel à la fois.