Aller au contenu

Filament ABS

stef_ladefense

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

Messages recommandés

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 1
  • 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

Bonjour @stef_ladefense,

ayant acheté une carte MKS 1.5 pour ma Discoeasy, j'ai voulu téléversé mon programme dans la carte. Malheureusement, le port  est grisé dans L'IDE. il n'y a même pas une led qui s'allume sur la carte (remarque, peut être qu'il n'y en a pas...). Je  pense que la carte est vide. Je vais donc essayer de charger le bootloader avec ta procédure décrite à partir de "Il existe une autre façon de flasher etc...). J'ai néanmoins une question car je ne suis pas sûr de la pin D53 sur ma carte (d'après mes recherches, elle se trouverait dans un des connecteurs dédiés à l'écran). Dans ta procédure, tu dis qu'il faut relier le borne reset à la borne D10 (uno) ou D53 (2560) de la carte cible, or sur l'interface Nano que tu as câblé, le reset est déjà relié à la borne D10 de l'interface. Ma question est donc, ai-je le choix de brancher le reset, soit de la carte interface (dans mon cas une UNO) sur la pin D10, soit brancher le reset sur la cart cible (D53 dans mon cas... si je la trouve) ?

Merci d'avance pour la réponse et surtout merci pour le temps consacré à partager ton savoir et à nous pondre de tel tutoriel.

Steam

Partager ce message


Lien à poster
Partager sur d’autres sites

oui c'est la borne reset de la carte que tu flash, que tu branches sur D10 sur l'uno ou le nano qui sert d'interface de prog, ou D53 si tu utilises une mega2560 comme interface de prog.

sur la carte cible, tu utilises le port icsp et c'est tout

maintenant, ta carte mks sans bootloader c'est bizarre, alors déjà, c'est quoi sont circuit d'interface usb ? ces drivers sont installés ? il y a quelques choses qui apparaît dans le gestionnaire de périphérique quand tu branches la carte ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour @stef_ladefense,

merci pour ta réponse. Je viens de comprendre, le reset de la carte cible va sur la borne D10 ou D53 de la carte interface. Je pensais que ce reset allait sur D10 ou D53 de sa propre carte. je comprends mieux ton montage avec la carte nano.

Quand je branche la carte MKS 1.5 , je n'ai rien, Quand je veux téléverser j'ai un message de mémoire "le port série selectionné n'existe pas ou votre carte Arduino n'est pas connectée". Quand je fais "recopier le message d'erreurs" dans l'ide Arduino et que je le colle dans word j'ai deux pages.  Dans le gestionnaire des périphériques, je n'ai aucun défaut qui apparaît. Quand je rebranche la carte MKS 1.0 (celle que je veux remplacer) je n'ai aucun soucis, la carte est détectée.

Faisant la manip sur un autre ordi, je peux copier ici le message d'erreur si cela peut aider.

Steam

Edit : j'ai fait la manip et voici la liste d'erreurs au format .doc

Arduino.doc

Modifié (le) par Steam
Ajout du fichier liste d'erreur.

Partager ce message


Lien à poster
Partager sur d’autres sites

Je m'excuse auprès de la modération pour ce double post.

@stef_ladefense Que veux-tu dire par :

il y a une heure, stef_ladefense a dit :

c'est quoi sont circuit d'interface usb ? ces drivers sont installés ?

Cela fonctionne avec toutes mes autres cartes, j'en déduis donc que les drivers sont bons.

Pour faire ta procédure de charger le Bootloader, je suppose que la carte doit être nu, c'est à dire sans rien de brancher dessus ou puis-je le faire in situ avec tous les organes de la machine branchés sur la carte ?

Steam

Modifié (le) par Steam

Partager ce message


Lien à poster
Partager sur d’autres sites

@stef_ladefense,

Le pont ?

J'ai réussi à téléverser le Marlin. Comment ai-je fait ...

En vue de charger le bootloader dans la carte, j'ai tout débranché sur la carte et je me suis dit que je vais, par acquis de conscience, refaire un tentative. Je branche mon câble USB et  là, étonnement, une led rouge allumé sur la carte. Je tente le téléversement. Port "Serie n'existe pas". Comme j'avais branché entre temps un clé USB pour transférer ici ma liste d'erreurs, j'ai fermé l'ide et je l'ai relancé, j'ai branché le câble, dans "outils", "port" j'ai cliqué sur "USB 83 Et j'ai téléversé le programme.

Une fois téléversé, j'ai tout rebranché, j'ai testé, et là il y a quand même des moteurs qui font un drôle de bruit, notamment les moteurs Z quand ils font le "Double touch" pour l'auto nivellement. J'ai également constaté que ces moteurs Z étaient très chauds, je pense qu'il faut régler les pololus, non ?

Une fois le tout rebranché, j'ai refait un téléversement et là cela c'est passé sans problème.

Je ne comprends pas pourquoi lors de ma première tentative avec tout branché sur ma carte cela ne fonctionnait pas ...

En tout cas, merci pour ton aide et merci pour la mise à disposition de ta procédure, je vais la garder précieusement.

Steam

Partager ce message


Lien à poster
Partager sur d’autres sites

oui c'est un FTDI232, un PL2303, un CH341, il y en a beaucoup de différent, et il n'y a pas de drivers magics qui marche à tout les coups

Partager ce message


Lien à poster
Partager sur d’autres sites

là je crois que tu m'emmènes dans monde inconnu pour moi. Comment je peux déterminer ce pont ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour @stef_ladefense

D'après la description :

" USB Driver Chip FT232RL"

Dans la description de la carte, il y est également indiqué :

" Fusible récupérable pour protection contre les courts-circuits. "

Est le composant qui se trouve juste à côté du connecteur USB sur la carte. Je pose la question car un autre forumeur a "cramé" plusieurs cartes en téléversant le programme. Si oui, où trouver la valeur de ce fusible ?

Le lien vers ma carte :

https://www.banggood.com/fr/MKS-Base-V1_5-3D-Printer-Control-Board-With-USB-Mega-2560-R3-Motherboard-RepRap-Ramps1_4-p-1144424.html?rmmds=myorder&cur_warehouse=CN

Steam

Modifié (le) par Steam

Partager ce message


Lien à poster
Partager sur d’autres sites

ok donc c'est un FTDI, espérant que c'est un vrai, sinon c'est chiant niveau drivers, mais tu dois les trouver sur le site du constructeur de la carte.

ton lien n''est pas un lien

fusible ? rien a voir, mais d'apres ce que tu dis, je dirais plutôt réarmable que récupérable 

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


×