avrdude: stk500_recv(): programmer is not responding

Oggi cercando di aggiornare a una nuova versione il firmware ho avuto questa splendida sorpresa... e sono ancora in lotta per risolverla..

Binary sketch size: 34586 bytes (of a 63488 byte maximum)
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding


ho gia' provato con il reset + upload

i miei dati sono:
Osx 10.7.5
sanguino 0023r4
arduino 0023
FTDI 2_2_18
sprinter (https://github.com/kliment/Sprinter/tree/master/Sprinter)

io sono nel panico.

messaggi in verbose mode

avrdude: Version 5.4-arduino, compiled on Oct 9 2007 at 11:20:31
Copyright (c) 2000-2005 Brian Dean, [www.bdmicro.com]

System wide configuration file is "/Users/ifala/Desktop/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf"
User configuration file is "/Users/ifala/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port : /dev/cu.usbserial-A800EU98
Using Programmer : stk500v1
Overriding Baud Rate : 57600
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: Send: Q [51] [20]
avrdude: ser_recv(): programmer is not responding

non so piu dove mettere le mani...

ho Risolto.

In pratica, con osx e i driver forniti con arduino ultima versione 1.01
se il mac viene da uno stand-by, non riesce a riconnettersi all'interfaccia... ( sanguinololu o ramps 1.4)

quindi basta riavviare il mac, et voillà....

Ieri, ho avuto incredibilmente lo stesso problema.

E adesso sono dinuovo a smadonnare, ho provato a fare i passaggi con il discorso dello stand-by ma non funziona.

non capisco veramente quello che succede... tra l'altro ho lo stesso problema con la RAMPS 1.4... ovvero sempre lo stesso errore e di conseguenza non riesco a modificare il firmware.

Mi viene voglia di mettere un linux da qualche parte e provare con quello... per vedere se lo carica.

Tutte le impostazioni della seriale sono corrette
Ieri, ho avuto incredibilmente lo stesso problema.

E adesso sono dinuovo a smadonnare, ho provato a fare i passaggi con il discorso dello stand-by ma non funziona.

non capisco veramente quello che succede... tra l'altro ho lo stesso problema con la RAMPS 1.4... ovvero sempre lo stesso errore e di conseguenza non riesco a modificare il firmware.

Mi viene voglia di mettere un linux da qualche parte e provare con quello... per vedere se lo carica.

Salve a tutti.
Ho anch'io lo stesso problema, da diverse settimane sto cercando di installare un qualsiasi firmware sulla sanguino, senza risultato.
Innanzitutto ho scoperto che la versione 1.0.1 di arduino NON FUNZIONA con sanguino, dunque ho rispolverato la vecchia versione 23.
Ho anche notato che è importante dove i file vengono installati, se le cartelle non hanno il nome esatto nascono problemi.
Poi ho anche letto che in questi casi è necessario provare con velocita' diverse per l'USB, modificando i parametri del baudrate in boards.txt della cartella hardware/Sanguino, mettendolo a 38400 invece di 57600.
Non riuscendo a flashare il micro, ho anche provato ad aggiungere esternamente un'interfaccia Serial/Usb, che almeno dispone dei led TX RX per osservare cosa succede. In fase di programmazione lampeggiava per l'eternità il led TX, ma la programmazione non arrivava mai alla fine, come se ci fosse un problema di comunicazione.
Quancuno dispone di un dettagliato tutorial su come flashare questa dannata scheda?
Grazie per la collaborazione.
Eugenio (Gorizia)

non capisco 38400?? io sono a gestire sia ramps sia sanguinololu 1.3a tutte a 250000, non ho mai modificato valori in boards.txt ma solo il valore in configuration.h nel firmware e questo vale sia per sprinter che per marlin, entrambi con più o meno le stesse voci da settare.
Per quanto riguarda la versione 23 è esattamente così... le 1.x non vanno

// This determines the communication speed of the printer
#define BAUDRATE 250000
//#define BAUDRATE 115200

questo è il parametro nel firmware

e questo è quanto ho dovuto modificare.... ed hanno sempre funzionato correttamente....
Non è che avete dei problemi nella porta seriale dei pc? qualsiasi altra cosa attaccate funziona?
scusate la banalità della domanda ma a volte sfuggono delle cavolate che poi compromettono tutto....

Avete controllato l'impostazione del jumper di autoreset?
Anche se può sembrare banale, di solito il problema è quello.

Per Sanguino vedi: [sanguino.cc] alla voce "Autoreset Enable"

Fatemi sapere se funziona

immaginaecrea Wrote:
> non capisco 38400??
> // This determines the communication speed of the printer
> #define BAUDRATE 250000
> //#define BAUDRATE 115200
>> questo è il parametro nel firmware


I parametri da te citati sono quelli del dialogo con il PC in fase di stampa.
Quelli a cui mi riferivo sono quelli del programmatore, ovviamente del tutto indipendenti dal firmware in fase di caricamento.
Ciao
Eugenio

Sulla mia scheda il jumper e' sempre presente, dunque l'autoreset dovrebbe essere sempre abilitato.
Ma il problema persiste con il jumper, senza il jumper ed anche resettando manualmente il micro appena il software è compilato, poco prima dell'upload.
Mi viene il sospetto che questi problemi siano nati nella sanguino versione 1.3, visto che sono relativamente sorti da poco.
C'e' qualcuno del Friuli, in modo da poter verificare e risolvere di persona il problema?
Grazie
Eugenio


tombo9999 Wrote:
-------------------------------------------------------
> Avete controllato l'impostazione del jumper di
> autoreset?
> Anche se può sembrare banale, di solito il
> problema è quello.
>
> Per Sanguino vedi: [sanguino.cc]
> alla voce "Autoreset Enable"
>
> Fatemi sapere se funziona

ciao spectrum niente news?
riprostinato?
che sistema operativo usi?

Allora spero di aver risolto per l'ennesima... VOLTA!

Per escludere tutti i problemi di connessione.... appunto come sembra essere il seguente problema...( di connessione)
Ho ripassato con il saldatore tutte le saldature della USB.

ET-VOILLA' ! con il trucchetto del tasto premuto del reset fino all'apparizione della scritta su arduino...
mi ha iniziato ad Uppare il Firmware!!!

Quindi... presumo che il mio problema fosse legato direttamente alla presa USB, e a niente più.

Purtroppo la scheda sanguino mi sta facendo sanguinare il cuore.
Dopo un mese di tentativi dove è stato provato praticamente tutto, la scheda non accetta nessun firmware.
Evidentemente è guasta e il peggio è che gli olandesi se ne sbattono.
Ora sto allestendo una nuova scheda basata su Atmega1284 e vedro' di usare i driver pololu che ho, altrimenti la collegherò a dei driver esterni.
La meccanica autocostruita è già pronta da tempo, mi manca solo l'elettronica.
saluti
Eugenio

Edited 1 time(s). Last edit at 11/29/2012 04:30AM by Spectrum.

Ciao a tutti, non sono un esperto di arduino ma anche a me dava questo poblema.
Un semplice programmino per accendere un led sul pin 13 non andava.
Al caricamento mi stampava il seguente messaggio in colore arancio su sfondo nero:

avrdude: stk500_recv(): programmer is not responding

Per risolverlo io ho fatto così:
Basta andare su

Strumenti -> Porta Seriale

e selezionare la porta giusta.

Nel mio caso era la

/dev/ttyACM0

Premetto che il mio sistema operativo è Ubuntu (Linux ) su altri sistemi non saprei come fare penso sia comunque analogo.
Spero di avervi aiutato a trovare il problema :-)

Magari fosse così semplice...
La seriale è uno dei primi parametri da settare e non credo nessuno possa sbagliare.
Fatto sta che con il nuovo micro ATmega1284 riesco a flashare al primo colpo (dopo aver caricato il bootloader), mentre con quel dannato 644 appare sempre il solito errore : avrdude: stk500_recv(): programmer is not responding
E' evidente che il problema sta nell'ambiente "Sanguino" caricato in Arduino per far riconoscere il micro.
Ci dev'essere qualche errore di configurazione che non sono ancora riuscito ad isolare, mentre per le versioni 1284 tutto è a posto.
Saluti
Eugenio