arduino uno r3 bloccato

ciao,
dovo averlo utilizzato per un bel po', il mio arduino uno r3 si è bloccato.
Quando lo connetto, si accendono il led power e quello collegato al pin 13 e restano accesi fissi. Windows7 vede il dispositivo sulla com5. Quando cerco di caricare uno sketch vedo qualche accensione del led Rx, e poi ricevo l'errore "avrdude: stk500_getsync(): not in sync: resp=0x00"

cosa posso fare?

E cos'hai fatto per bloccarlo? Qual è l'ultimo sketch caricato?
Hai provato la "manovra di emergenza" (cerca sul forum)?

non saprei di preciso cosa ho fatto...la manovra di emergenza l'ho provata una manciata di volte, senza risultato.

leo72:
Qual è l'ultimo sketch caricato?

credo un ReadWrite per la SD.
Aggiungo che lo stato dei led è lo stesso (cioè power e led13 accesi fissi) anche senza il controllore installato...

Il led "L" sulle UNO R3 può restare acceso di suo, c'è un piccolo bug nella progettazione della scheda. Se tocchi l'attacco posteriore del pin 13 si dovrebbe spengere (fai massa col corpo).

Ma provando la manovra di emergenza che messaggi di errori ricevi?

avrdude: stk500_getsync(): not in sync: resp=0x00

il led L se tocco il pin 13 da dietro diminuisce di intensità, ma non si spegne...

l'ultimo passo della manovra è criptico, che significa "se hai trovato la sincronizzazione giusta tra la pressione del pulsante grafico di upload dello sketch ed il rilascio del reset, verrà caricato lo sketch"?

windrob73:
l'ultimo passo della manovra è criptico, che significa "se hai trovato la sincronizzazione giusta tra la pressione del pulsante grafico di upload dello sketch ed il rilascio del reset, verrà caricato lo sketch"?

Non è criptico, è una questione di tempi.
Devi trovare il momento giusto in cui rilasciare il pulsante di reset. Se lo fai troppo presto, il bootloader riesce a cedere il controllo allo sketch in memoria prima che l'IDE riesca a contattare il bootloader stesso ed instaurare la programmazione, se lo fai troppo tardi, quando l'IDE contatta il bootloader, questo non è ancora partito e quindi l'IDE dà errore.

leo72:
Il led "L" sulle UNO R3 può restare acceso di suo, c'è un piccolo bug nella progettazione della scheda. Se tocchi l'attacco posteriore del pin 13 si dovrebbe spengere (fai massa col corpo).

In cosa consisterebbe questo "hardware bug"?

In questo:
http://forum.arduino.cc/index.php?topic=127396.msg958330#msg958330

Io ho risolto modificando il bootloader in modo che ponga in output/low il pin 13, così che l'op-amp abbia uno stato basso ben definito, evitando che venga attivato dalla piccola corrente che esce dal pin in alta impedenza.
http://www.leonardomiliani.com/2013/una-soluzione-per-il-problema-del-led-integrato-sempre-acceso-sulle-uno-r3/

Ah , ho capito, ...un bug? Mmm , secondo me il progettista ha scelto consapevolmente di non mettere alcuna resistenza di tiro in quanto voleva caricare il pin il meno possibile in modo da lasciare all'utente finale la possibilità di utilizzarlo anche come ingresso ad alta impedenza

Ma bastava una R di valore molto elevato per eliminare il problema lasciando le caratteristiche del pin inalterate.

ok, faccio qualche prova e vi faccio sapere.

grazie a tutti. :slight_smile:

niente da fare...resta acceso sempre, anche senza il 328 montato sopra...si sarà rotto qualcosa nella scheda...
boooooo

io ho avuto lo stesso identico problema, ma lasciando arduino inutilizzato per un paio di mesi, non avevo micro per provare quindi avevo il dubbio che fosse il bootloader, ma a quanto pare non è così.. a quanto pare è successo a piu di qualcuno, non è che sia un difetto? sono disponibile a spedire la mia scheda e a farla analizzare da qualcuno, almeno si risolve il problema

leo72:
Il led "L" sulle UNO R3 può restare acceso di suo, c'è un piccolo bug nella progettazione della scheda. Se tocchi l'attacco posteriore del pin 13 si dovrebbe spengere (fai massa col corpo).

Ma provando la manovra di emergenza che messaggi di errori ricevi?

Scusate se mi intrometto ma non ho capito questa cosa: di quale bug parli?Come può rimanere acceso perennemente il led L anche senza micro?

Non è propriamente un bug ma un comportamento indesiderato del circuito che è stato progettato sulla UNO modello R3 per il pilotaggio del LED. Viene usata la seconda metà dell'operazionale che era già presente sulla scheda (per switchare l'alimentazione da jack a porta USB) in modalità inseguitore di tensione. Però non hanno inserito una R di pull-down per cui l'op-amp sente la piccolissima corrente che scorre dal pin in alta impedenza (tutti i pin all'accensione sono impostati come input) ed accende il led.
Il primo a capire il motivo è stato Uwe, che ha spiegato questa cosa sul forum mesi fa.

per risolvere la questione in attesa di una correzione hardware in una ipotetica versione futura, ho preparato un bootloader modificato che imposta il pin in output con segnale low.

Si ho letto un topic sull'argomento e fino al voltage follower son d'accordo... quello che non capisco è come fa l'LMV35 a rilevare questa debolissima corrente se fisicamente il suo pin non invertente non è collegato a nulla (nel caso in cui il 328non è presente sullo zoccolo)? Teoricamente, se non ricordo male la teoria sugli operazionali, in questo caso, essendo il pin a vuoto, l'uscita dell'operazionale è aleatoria (potrebbe essere tanto bassa quanto alta a causa dei "rumori") in quanto per l'appunto basta una debolissima corrente a portare l'uscita sullo stato alto....

Sì ma difatti il problema è proprio derivato dal fatto che resta flottante.
Basterebbe una pull-down da 100K per risolvere il problema, dando un segnale basso sicuro.

La modifica al bootloader che ho fatto io fa proprio questo: mette il pin 13 in output con segnale LOW in modo che quel pin abbia un segnale basso definito e l'operazionale non accenda o spenga il led a seconda se "sente" qualcosa o meno. Certo, c'è il rischio derivante dal fatto che se l'utente non si ricorda di questa cosa ed al pin 13 c'è collegato qualcosa che fornisce corrente, allora il corto è assicurato... ma è una cosa, il bootloader modificato, che la gente installa di proposito, quindi spero che non faccia danni...

In attesa, magari, di una UNO R4 che risolva via hardware il problema.