Pb Chargement de Firmware sur GEN7.1.4.1

Bonjour,

Je suis en train de monter une PRUSA MENDEL V.2 et j'ai un problème pour charger un firmware.
Je suis sous Seven X64 avec une GEN7.1.4.1. & une ATMEGA644 20P, j'ai testé ARDUINO 0018, 0023 et le 1.0.1. mais rien à faire.
Voici donc ce que j'ai fait:

J'ai branché le USB/TTL,
J'ai mis le FTDI driver 2.08.24 de la page [www.ftdichip.com] ==> OK

Je dl ARDUINO0023,
Je dl le Gen7 Arduino IDE Support et copie tout ce qu'il y a dans GEN7 ( bootloaders, core, variant, boards.txt) dans le dossier ARDUINOXXX\Hardware\arduino\ histoire de fusionner, copier et remplacer ce qu'il y a déjà.

J'ouvre le firmware de test, je le charge et j'ai bien la led qui clignote... et je vois bien ce qu'il se passe avec le moniteur de série. Donc la communication se fait bien? J'ai un disque dur partitionné et les ARDUINO ne sont pas sur C: mais sur D: logiquement cela ne change rien?

TEST DE TEACUP:

Avec ARDUINO0023:
Au cas où je désactive l'antivirus et le pare-feu et déconnecte toutes les connections de la carte sauf l'alim et les controleurs de moteur pas à pas (carte éteinte évidement),
Je Dl le triffid-Teacup_Firmware-915dc42.zip,
Je le renomme en Teacup_Firmware,
Je remplace config.gen7-v1.4.h par config.h & ThermistorTable.double.h par ThermistorTable.h,
pour l'instant je veux juste vérifier que les moteurs sont commandés donc pas de modifs de firmware pour l'instant sauf le BAUDRATE que je passe à 38400 à caus e de l'ATMEGA644 (dans ARDUINO, config.h que je referme pour sauver la modif).
Je le recharge (open, puis teacup_firmware.pde),
Je vérifie ==> OK (Done compiling), j'ouvre le serial monitor histoire histoire de vérifier que le port est libre ==> OK
J'Upload... "Uploading to ie board, binary sketch size..." .... ..... ......
15 minutes après message:
avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer
avrdude: stk500_2_ReceiveMessage(): timeout...

J'ai essayé avec la bidouille de chronomètrer le temps de compilation pour appuyer sur reset de la carte et relacher avant ce temps car apparement la carte prend les chargements de firmware dans les 3 secondes après le relachement de reset.

Je ferme ARDUINO, J'éteinds l'alim, débranche l'usb, rallume l'alim et rebranche l'usb,
Je lance pronterface (le pack avec skeinforge, plater.exe, pronsole.exe...) avec le bon port à 38400 bauds:
PRONTERFACE: connect... ... .... Connecting.... .... .... .... .... et rien

J'ai renvoyé la carte qui aété testé avec confirmation qu'elle fonctionnait bien et j'ai retesté à son retour mais toujours pareil.

J'ai passé + de 4 jours à tout tester et la seule chose que j'ai réussit à faire c'était faire chauffer la buse avec REPETIER et le REPETIER HOST mais pas plus.

Je comprends pas et commence à croire qu'il faille que je prenne l'option massue et hache voir tronçonneuse et lance-flamme...

Merci par avance de votre retour.

Salut,
Bon si j'ai à peu près compris, t'arrives de pas à bien gérer l'upload du firmware.
Tu as la bonne configuration en terme de port, bootloader, et baudrate puisque tu as réussi à uploader repetier.

Faut tout d'abord savoir que les FTDI ont un pin reset et comment s'opère le chargement du firmware par le bootloader.
Dans notre cas c'est en général un petit délai avant le lancement du firmware (dans les 2 3 secondes je pense)
Faut aussi savoir que les FTDI de sale qualité ont le reset qui chie-ou peut être qui marche différemment- (j'en ai un chinois à 3€ qui a le reset qui marche pas et un sparkfun qui marche).
Quand il marche c'est trop bien t'as juste à envoyer le firmware avec arduino 0023.
Quand ça chie moi je cliques sur l'upload en restant appuyer sur le reset de ma gen 7 je compte jusqu'à trois-c'est un truc
j'ai pas compris chez arduino, t'as pas de bouton upload sans compilation, même pas caché, pour éviter les erreurs d'oubli de compil pour les débutants, pas con mais chiant dans notre situation- donc oui tu comptes jusqu'à 3 pour éviter le temps de compilation et tu lâches ton reset en essayant de tomber juste avant qu'il te dise qu'il a compilé et qu'il envoi le pâté.

Pour info ça sert à rien d'attendre 15min si tu vois qu'il a fait clignote au moins une fois tes led de ton FTDI
tu peux tuer le processus avrdude.-t'exite pas en voyant upload done, ça a pas marché :-P-
En espérant que ça t'emmène sur la bonne voie...

Yopla BOoo

Je suis un peu perplexe sur le baud-rate, j'essayerais plutôt avec une valeur de 115200 bauds.

Peace.

---

_{"Ils ne savaient pas que c'était impossible alors ils l'ont fait!" Mark Twain
[DOC][CONFIG] Hauteur de couche (Layer height)
Lautr3k - A 3D printer without belts
iTopie - A Swissmade RepRap}

Oui, pour souligner ce qu'écrit skarab, ya deux baudrate différents,
Celui du bootloader, dans le cas du stk500v2 -de base je crois bien à 115200 comme dit skarab-
Que tu ai modifié le firmware ne change pas le bootloader.

Donc arduino 115200
Host reprap 38400

Haaa bien vu Skarab, me semble bien que repetier de base est réglé sur 115200 !

Merci pour votre retour.

Je remet baudrate à 115200 dans config.h du firmware teacup, je fais la manip de Ghunt:
Envoi du bootload,
reset pendant environ 3 secondes et relachage...
Done Uploading en moins de 30 secondes => KOOL ça marche.

Je lance Pronterface, PORT5 (dans mon cas) avec @ 38400,
connect... ..... ...... 10 minutes et rien
Bloqué sur Connecting...
Je refais de même avec @ à 115200
connect... ..... ...... 10 minutes et rien
Bloqué sur Connecting...
Je refai pareil en débranchant et en rebranchant l'USB de série... même résultat


Je lance Repetier Host (en plus y'a une nouvelle version), port5, Baudrate 38400 (et après à 115200) puis Connect,
Dans l'onglet Manual Control j'appuie sur ok à droite des debug options,
"Idle" puis "1 command waiting",
J'appuie sur power qui devient vert puis ok plusieurs fois jusqu'à "Idle" puis "1 command waiting",
Je test le déplacement +X à 1mm puis ok puis 10mm puis ok plusieurs fois jusqu'à "Idle" puis "1 command waiting",
Le +Y à 10mm puis ok plusieurs fois jusqu'à "Idle" puis "1 command waiting",
Résultat rien ne se passe et j'ai en rouge 11,00 au dessus de +X et 10,00 au dessus de+Y...........
Et au bout de 5 minutes rien ne bouge.

Là, du coup, je vois pas trop la manip à faire quand je lance pronterface ou repetier? J'ai oublié quelque chose? J'ai aussi chargé le firmware de repetier mais résultats identiques.

Une autre question, si je lance Arduino, que j'ouvre le moniteur de série et que j'appuie sur reset de la carte, je devrais pas voir quelque chose du style "board is idle" ou autre? parceque moi j'ai rien.

Si tu fais un hardreset sur ta carte et que tu te tiens en face de ton moniteur série tu devrais voir un:
Start ok
Wait

Aparraitre, sous repetier il répète le "wait" indéfiniment.
Tester les différents baudrate me paraît une bonne idée, mais il devrait y avoir quelques choses écrites, ne serait-ce que des caractères qui ne veulent rien dire (mauvais baudrate).

Retente toute la manip la tu m'étonne un peu de pas pouvoir voir quelque chose en réussissant d'envoyer le firmware.

Tu peux aussi envoyer l'exemple ASCII table de arduino que tu trouvera dans les onglets de l'application, teste ça, sans plus d'informations ça m'est dur de t'aider.
Et Repetier Host marche mieux avec le firmware adapté

Yep je confirme l’étrangeté de la chose, perso j'ai jamais tester Teacup, mais avec le couple Repetier host / firmeware pas de soucis, enfin pas de cette ordre la^^

Peace.

---

_{"Ils ne savaient pas que c'était impossible alors ils l'ont fait!" Mark Twain
[DOC][CONFIG] Hauteur de couche (Layer height)
Lautr3k - A 3D printer without belts
iTopie - A Swissmade RepRap}

Bon à moins que ma carte soit hantée... pour résumer avec ARDUINO0023 et le firmware repetier avec la bonne carte de choisie (#define MOTHERBOARD 71).

Je charge le firmware => Done Uploading => ok

Je reste sur ARDUINO,
J'ouvre le moniteur série,
J'appuie sur le reset de la carte....
Et il n'y a rien qui apparait (test avec tous les baudrates du moniteur au cas où).

En bas du configuration.h il y a les lignes:

Overridden if EEPROM activated.
*/
//#define BAUDRATE 76800
//#define BAUDRATE 115200
#define BAUDRATE 250000
/** \brief Size in byte of the output buffer */
#define OUTPUT_BUFFER_SIZE 64
/** \brief Activates buffered output.

The Arduino libraries have a buffered input for serial connections. Write operations are
always unbuffered, which means the controller will wait with execution, until the data
is send. To solve this handicap, all write operations have to use out insted of Serial.
If you uncomment this, you still have to use out, but it will use no buffers, so you
keep with your slow communication version.
*/

/**
Some boards like Gen7 have a power on pin, to enable the atx power supply. If this is defined,
the power will be turned on without the need to call M80 if initially started.
*/
#define ENABLE_POWER_ON_STARTUP

J'ai testé pas mal de #define BAUDRATE sans succès.
Ne faudrait-il pas que je fasse quelquechose ici pour "activer" la carte?

Il y a également ces renseignements avec teacup:
[reprap.org]

Vu que j'ai une ATMEGA 644 le baudrate à 38400 dans configuration.h, c'est pas une bonne idée?
Est-ce que ça change quequechose pour le moniteur de série ARDUINO?

Ou tout simplement changer de câble?

Merci par avance.

Ça me paraît zarb ton histoire,

Teste l'ascii exemple, tu nous dis ce que tu vois.
Si ça marche Ya un exemple que tu devrais tester : c'est l' eeprom clean exemple avant de retenter repetier avec le baudrate 19200

Teste ça et dis nous ce que ça donne

Yep alors l'ASCII exemple donne dans le moniteur série, après reset sur la carte:

ASCII Table ~ Character Map
!, dec: 33, hex: 21, oct: 41, bin: 100001
", dec: 34, hex: 22, oct: 42, bin: 100010
#, dec: 35, hex: 23, oct: 43, bin: 100011
$, dec: 36, hex: 24, oct: 44, bin: 100100
%, dec: 37, hex: 25, oct: 45, bin: 100101
&, dec: 38, hex: 26, oct: 46, bin: 100110
...... ..... .....
x, dec: 120, hex: 78, oct: 170, bin: 1111000
y, dec: 121, hex: 79, oct: 171, bin: 1111001
z, dec: 122, hex: 7A, oct: 172, bin: 1111010
{, dec: 123, hex: 7B, oct: 173, bin: 1111011
|, dec: 124, hex: 7C, oct: 174, bin: 1111100
}, dec: 125, hex: 7D, oct: 175, bin: 1111101
~, dec: 126, hex: 7E, oct: 176, bin: 1111110

Puis exemple EEPROM clear =>ok (y a plus rien dans le moniteur après reset)

Puis chargement de repetier avec baudrate à 19200 ==> toujours rien dans le moniteur après reset.
Re-clear puis chargement avec le baudrate à 38400 ==> toujours rien dans le moniteur après reset.
Re-clear puis chargement avec le baudrate à 115200 ==> toujours rien dans le moniteur après reset.
(J'ai passé ts les baudrates du moniteur en revue)

Y'a également 3 lignes en dessous de tout ça:

#if !defined(__AVR_AT90USB1286__) && !defined(__AVR_AT90USB1287__) // not needed for USB serial
#define USE_BUFFERED_OUTPUT
#endif

Là j'ai testé de rajouter // devant les 3 lignes car j'ai un câble USB/TTL et tjrs rien.

J'ai aussi essayer de passer le #define OUTPUT_BUFFER_SIZE 64 à 32 mais rien...

J'ai également vu cette partie qui est à la suite du baudrate... sur interchouet:

The Arduino libraries have a buffered input for serial connections. Write operations are
always unbuffered, which means the controller will wait with execution, until the data
is send. To solve this handicap, all write operations have to use out insted of Serial.
If you uncomment this, you still have to use out, but it will use no buffers, so you
keep with your slow communication version.
*/
#define USE_BUFFERED_OUTPUT
/** \brief Number of moves we can cache in advance.

La ligne en bleue n'est pas mentionnée dans le configuration.h, j'ai testé de la rajouter mais encore rien.

J'ai retesté teacup et rien dans le moniteur.

J'utilise couramment host repetier et teacup sur gen7, sans probleme.
Il a fallu juste que je coche 'use ping pong communication' dans printer settings pour eviter les freezes.
Je te ressort une ancienne discussion la dessus:

[forums.reprap.org]

Tu peux mettre a 115200 bauds meme avec un 644p

Par contre je comprend pas bien pourquoi tu fait des essais a plusieurs vitesses.
Si dans le configuration.h tu mets a 115200, dans le host repetier tu mets a 115200 et point barre ?

Si tu as encore un probleme avec repetier. Essaye en ligne de commande avec pronsole.py , c'est simple a utiliser, leger..si ca marche pas avec ca. C'est qu'il y a un souci hard.

---

-----------------------------------------------------------------------------------------------------------
blog Paoparts

Merci paoparts mais là je suis très loin de l'impression, j'ai même pas pu tester et regler les moteurs...

En fait je bloque au niveau de la communication, après avoir chargé un firmware avec ARDUINO, j'ouvre le moniteur série et fait un reset sur la carte et là rien n'apparait dans le moniteur, ce qui apparament est loin d'être normal.

Par contre je note le lien ça pourrait me servir par la suite, enfin si je passe l'étape communication.

La tu m'étonne un peu, à mon avis t'as chier ta config.

Ce que je ferai c'est un eeprom clean + paquetage repetier qui sort tout frais du zip sans rien toucher.. A part le motherboard 71

#include 
void setup()
{
  for (int i = 0; i < 512; i++)
    EEPROM.write(i, 0);
}
void loop()
{
}

Essayes de mettre ça dans Arduino. Tu uploades, et tu fais un reset derrière. Ca effaces tout l'EEPROM.
Ensuite comme dis Ghunt, reprends un zip directement du Github avec la dernière version du Repetier. Change juste la configuration de la carte (au tout début du fichier configuration), en mettant

#define MOTHERBOARD 71

Tu complies/Upload avec Arduino.
Normalement avec Teacup tu devrais pas avoir de problème : il ne prends pas en compte l'EEPROM.
Sinon après il faut appeler un exorciste !

Bon alors BOoo, t'en es ou? moi je suis impatient de connaitre la réponse...

Rhooo il a le droit de prendre des vacances quand même ! :-)

Bonsoir,

J'ai un problème similaire, bien qu'un peu différent:
_j'ai construit une Prusa V2, avec un Gen7 v1.4.1 (atmega1284P)
_j'ai branché la gen7 uniquement via le port USB/TTL (testé l'adaptateur en loopback: je reçois bien ce que j'envoie)
_une fois la carte branchée, seule la led orange s'allume (en continu), rien ne fume...
_j'ai installé l'IDE Arduino avec le pack pour la Gen7 (je précise au passage que j'ai dû rétrograder Java 6 pour Java 5 car l'IDE plantait dès que j'essayais d'ouvrir un fichier... avis aux concernés ;p )
_j'ouvre le fichier "SetupTest.pde" et je clique sur "téléverser"
_mon ordi compile puis tente d'envoyer le fichier (led orange allumée, aucune led ne clignote) puis m'engueule:

         Using Port                    : \\.\COM19
         Using Programmer              : stk500v2
         Overriding Baud Rate          : 115200
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14] 
avrdude: Recv: 
avrdude: stk500v2_ReceiveMessage(): timeout

et réitère ses tentatives en boucle...
_j'ai essayé d'appuyer sur reset juste avant que l'ordi n'essaye de communiquer: rien à faire !
_j'ai contrôlé le reset au multimètre: pas de court-circuit sur l'interrupteur, il fait bien son boulot...

On m'a signalé que le baudrate était peut-être en cause, mais je n'arrive pas à le changer... quelqu'un a-t-il une idée?
Merci...

Je vais réutiliser ton message, j'ai la tete un peu en vrac, ca me permettra d'y voir un peu plus clair...

Quote
yaesen
J'ai un problème similaire, bien qu'un peu différent:
_j'ai construit une Prusa V2, avec un Gen7 v1.4.1 (atmega1284P) => ok il faudra faire attention au compilateur
_j'ai branché la gen7 uniquement via le port USB/TTL (testé l'adaptateur en loopback: je reçois bien ce que j'envoie) =>Bien
_une fois la carte branchée, seule la led orange s'allume (en continu), rien ne fume... =>Bien
_j'ai installé l'IDE Arduino avec le pack pour la Gen7 (je précise au passage que j'ai dû rétrograder Java 6 pour Java 5 car l'IDE plantait dès que j'essayais d'ouvrir un fichier... avis aux concernés ;p ) =>Il integre de base l'atmega1284P?? de toute facon ca ne donnerait pas ce message
_j'ouvre le fichier "SetupTest.pde" et je clique sur "téléverser" =>OK
_mon ordi compile puis tente d'envoyer le fichier (led orange allumée, aucune led ne clignote) puis m'engueule:
Using Port : \\.\COM19
Using Programmer : stk500v2
Overriding Baud Rate : 115200
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14]
avrdude: Recv:
avrdude: stk500v2_ReceiveMessage(): timeout
et réitère ses tentatives en boucle...
=>Pas de communication tu l'auras compris, peut venir de tout: ta carte qui ne fonctionne pas (possible)ou ton atmega (rare)
Sinon cela peut effectivement venir du baudrate (stk500v2 -de base je crois bien à 115200 baud-)
Le port oui, ca arrive de se planter de port mais tu dis avoir vu les communications avec un appareil tiers

_j'ai essayé d'appuyer sur reset juste avant que l'ordi n'essaye de communiquer: rien à faire ! =>mouai
_j'ai contrôlé le reset au multimètre: pas de court-circuit sur l'interrupteur, il fait bien son boulot... =>Ok

Pffff franchement le baudrate ca me parait étonnant, tu peux le changer dans le board.txt de ton arduino IDE dans le dossier hardware/gen7
Mais je te le conseille pas, a moins que tu ais modifié ton bootloader changé le baudrate et compilé maison mais vu ta question ca m'étonnerais... ou alors tu es allé chapardé le firmware dans un site sur internet précompilé avec un autre baudrate...


j'allais écrire ca:
Non pour moi je prendrais le tout dès le debut si j'avais un programmateur arduino ou un arduino en rab (pour programmer en ISP), en envoyant l'exemple ascii par ISP et non par le bootloader...
Bref faudrait être sur et certain que ta platine marche, faut eliminer des inconnues...

Ou alors....Ou alors??.... t'as vraiment un bootloader gravé dans ton atmega ??? Ou tu l'as acheté sans rien...Tu la sors d'ou ta carte et ton atmega??

Edited 1 time(s). Last edit at 10/08/2012 04:48PM by Ghunt.

Mon expérience Gen7 1.3.1 + Teacup (pas de différence je pense avec une Gen7 plus récente ou un autre firmware) :

- ne pas essayer de changer le baudrate qui est toujours à 115200 dans le firmware

- pour télécharger le firmware, lorsque l'alimentation est un bloc récupéré sur un PC, le cavalier de sélection de l'alimentation de la Gen7 peut rester en position d'utilisation normale, càd juste en-dessous du connecteur ATX 20/24. Donc le cavalier n'a pas besoin d'être déplacé selon ce qu'on fait, chargement du firmware ou utilisation de la machine

- pas de reset matériel de la Gen7 à faire lors du chargement du firmware

- une fois le firmware téléchargé, si on ouvre la console série d'Arduino, réglée à 115200 of course, le firmware répond :
"start" puis "ok" (un autre firmware répondra quelque chose de similaire j'imagine)

- on peut tester tout le fonctionnement de la machine depuis la console série d'Arduino, plateau, tête, les 4 moteurs :
• pour tester un moteur envoyer G1 X20 F1000 par exemple pour l'axe X (pour l'axe Z ne pas aller trop vite, F100 par exemple)
• pour tester le moteur de l'extruder, envoyer avant chaque essai un G92 E0, puis par ex. G1 E30 F50 (pour extruder 30 mm à 50 mm par minute)
• pour le chauffage de la tête envoyer M104 S55 par exemple, puis des M105 pour voir si la température suit
• pour le chauffage du plateau idem, avec M140 S55 par ex.

---

François

Salut Ghunt,

J'ai acheté mon ATMEGA chez Poaparts, compris dans le kit Gen7. J'ai passé la soirée d'hier soir à vérifier mes soudures, donc je crois que ça baigne de ce côté...

J'ai branché une alim ATX en plus sur ma carte et voilà ce que j'obtiens:

• Pas de cavalier sur les broches à côté du connecteur ATX24: led orange allumée, rien ne clignote. Je reçois toujours le message de timeout.
• Cavalier sur les 2 broches les plus éloignées du connecteur ATX: leds verte et orange du coin de la carte clignotent. L'IDE reste bloquée, pas de message de timeout.
• Cavalier sur les 2 broches les plus proches du connecteur ATX: led orange allumée, l'IDE me dit quelle reçoit "[00]"... appuyer sur reset allume la led verte à côté de la orange au bout de quelques secondes, puis la led du lit chauffant clignote pendant quelques secondes. Puis retour à la case départ...

Ca vous avance ?
Merci.

Edited 1 time(s). Last edit at 10/09/2012 01:15PM by yaesen.

Haha pas vraiment,

la bonne solution est la 3:

Quote

[*] Cavalier sur les 2 broches les plus proches du connecteur ATX: led orange allumée, l'IDE me dit quelle reçoit "[00]"...

Je sais pas si tu as lu la doc de la gen7 mais il est dit que ce jumper permet d'alimenter ton µC avec le connecteur ATX24, sinon l'autre permet (il me semble) de l'alimenter par les slots dédiés aux péripheriques Molex (je me rappelle plus de leurs nom).

T'as peut etre un court circuit quequ' part... T'as un firmware dans ton µC puisque la led verte s'allume, cela active la ligne 12V et ca chie.
Etonnant que cela arrive apres quelques secondes...

T'as rien de branché? Ni pololu ? ni rien sur la carte?

Edited 1 time(s). Last edit at 10/09/2012 02:19PM by Ghunt.

J'ai enlevé les polulus pour être sûr de pas les faire cramer au cas où...
Où est-ce que je peux trouver un mapping de l'atmega avec les tensions normales au démarrage de la carte? je pense démarrer par là pour chercher la panne...

Si ca viens de chez moi, donc le bootloader est chargé.
et en général le firmware de test est installé, ce que fait d’ailleurs le processeur d'après ce que tu précises:
le firmware de test fait clignoter la led du Heater 10 fois, ensuite il envoi sur la ligne série le texte "ATmega is idle" a vérifier sur la console série de l'IDE Arduino réglé sur 9600 bauds.

sur les dernières versions de GEN7 envoyé , j'ai mis teacup ( avec vitesse de 115200) , c'est précisé sur une pastille collé sur le processeur. mais je pense que pour le futur, je vais plutôt écrire un petit bout de code identique au firmware de test qui testera les principales fonctionnalités de la carte.


Pour les straps, bien suivre la documentation que j'ai pris soin de traduire à l'URL suivante . Il faut OBLIGATOIREMENT un strap, mais JAMAIS 2. le bon choix pour vous c'est le strap le plus proche du connecteur ATX24

Après avoir téléchargé le firmware Teacup, rebasculez le serial monitor ( la console) sur 115200 bauds ( si vous n'avez rien changé dans le fichier config.h )
normalement après reset. le processeur répond "start". vous pouvez taper par exemple M115, qui renvoi le nom du firmware
exemple renvoyé: FIRMWARE_NAME:Teacup FIRMWARE_URL:http%3A//github.com/triffid/Teacup_Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:1 TEMP_SENSOR_COUNT:2 HEATER_COUNT:3.
et si ca marche, essayez comme le précise les différentes réponses a ce topic, qqs commandes ( G0 X10.....

Si rien n'est retourné à la commande M115, rebasculez la vitesse dans le serial monitor sur 9600 bauds, reset du processeur. si vous retrouvez le comportement initial avec le firmware test, c'est que vous n'avez pas écrasé le premier firmware.
Reprendre alors la technique de chargement avec appuis sur Reset si nécessaire au bon moment... Il faut parfois insister. j'ai pas encore compris pourquoi. j'ai par exemple une GEN7 1.3 , un vrai régal suffit de lancer sans rien faire et ça marche tout le temps... la V1.4.1 est plus récalcitrante, quoique ? peut être du au changement du mode d’alimentation ( le mode alimentation par le port USB n'existe plus ). il faut que je pose la question à Markus.

Merci pour ces indications.

J'ai utilisé la console série et j'ai effectivement constaté que le contrôleur envoyait bien ses messages.
J'ai donc essayé de modifier légèrement le fichier de test (juste les messages, rien de difficile, je sais ce que je fais ici) mais après la compilation, impossible d'uploader le fichier sur la carte: il me ressort ce satané message de timeout...
Idem pour le firmware: compilation OK, mais upload KO... une idée d'où ça peut venir?

Merci beaucoup!

EDIT: j'ai persévéré en appuyant sur reset au bon moment, j'ai réussi à envoyer le firmware Teacup et j'ai eu la réponse suivante sur la console:

Y^«iEU

J'ai essayé de changer le baudrate de la console, mais je n'obtiens pas de décodage intelligible... et la commande M115 ne renvoie rien.

Edited 2 time(s). Last edit at 10/09/2012 04:17PM by yaesen.

Haaaa c'est donc ca le clignotement.... Moi qui croyais que tu avais envoyé le firmware au moins une fois...
Donc si la provenance de Paoparts (bon boulot au fait pour avoir mis un firmware de test...pas con...), tu oublies les histoires de courtcircuit... ca m'est deja arrivé... c'est pour ca
Suis les indications de Paoparts, en prems.

Bon...ben t'as plus qu'a trouvé la bonne config de ton IDE quoi...
Tu compiles, ca c'est pas trop dur mais t'arrives pas a faire le lien IDE<->µC (d'ou le timeout)
Atta... t'as mis la configuration dans arduino->tools->boards->gen7?? T'as fait la manip de rajouter dans l'IDE ta carte personnalisée?

Le coup du reset ouaip...sinon t'as fait de la merde avec ton IDE, t'as modifier des configs et blablabla, dans ce cas la tu recommences tout depuis le debut -fresh start- tu prends un IDE 023 clean et tu tentes Repetier par exemple et tu envois la purée...

Je vois pas trop ce que je peux rajouter sur le message de Paoparts...

Bon, maintenant, j'arrive tant bien que mal à envoyer des programmes sur la carte en appuyant sur reset au bon moment, mais la communication série ne fonctionne plus... elle fonctionnait avant que j'écrase le programme qui était d'origine sur la carte... les tempos sont bonnes, mais pas les strings renvoyées...

Tu n'as pas pu écraser le bootloader si c'est à ca que tu penses, tu peux uniquement le faire par ISP... (à 95% sur)

les tempos? temperatures?
les strings renvoyés?

Tu detaillerais pas un peu plus ?

je confirme pour le bootloader.

sinon pdt que j'y pense, il ne faut pas utiliser une version antérieure à 2.0 1.0 pour l'IDE arduino si tu as un processeur 1284P, c'est ton cas je crois. l'avrude ( celui utilisé avec l'ide 0023) ne marche pas avec ce processeur.

du coup je met à jour en temps réel la doc sur reprap gen7 fr

Edited 1 time(s). Last edit at 10/09/2012 05:15PM by paoparts.

---

-----------------------------------------------------------------------------------------------------------
blog Paoparts

Ghunt Wrote:
-------------------------------------------------------
> Tu n'as pas pu écraser le bootloader si c'est à
> ca que tu penses, tu peux uniquement le faire par
> ISP... (à 95% sur) Non, je pensais au programme de test chargé par Paoparts.
>
> les tempos? temperatures? Non, les temporisations (instructions delay()).
> les strings renvoyés? Les chaînes de caractères renvoyées par la carte via la liaison série.
>
> Tu detaillerais pas un peu plus ?

Voilà le code que je lui donne à exécuter:

#define PSU_Pin 15
#define HEATER_Pin 3
#define BED_Pin 4

void setup() {
  int i;

  Serial.begin(9600);
  pinMode(PSU_Pin, OUTPUT);
  pinMode(HEATER_Pin, OUTPUT);
  pinMode(BED_Pin, OUTPUT);
  digitalWrite(PSU_Pin, HIGH);   // initial value, off
  digitalWrite(HEATER_Pin, LOW); // intiial value, off
  digitalWrite(BED_Pin, LOW);    // always off

  // test procedure
  delay(5000);
  //Serial.print("Reveil alim\n");
  //digitalWrite(PSU_Pin, LOW);

  for (i = 0; i < 10; i++) {
    Serial.print("i = ");
    Serial.print(i);
    Serial.print('\n');
    //Serial.print("LED on\n");
    //digitalWrite(HEATER_Pin, HIGH);
    digitalWrite(PSU_Pin, LOW);
    delay(600);
    //Serial.print("LED off\n");
    //digitalWrite(HEATER_Pin, LOW);
    digitalWrite(PSU_Pin, HIGH);
    delay(600);
  }

  Serial.print("Extinction alim\n");
  digitalWrite(PSU_Pin, HIGH);
}

void loop() {
  Serial.print("ATmega inactif\n");
  delay(1000);
}