Non si caricano più gli sketch

Stavo pasticciando con un mio progetto (modifiche dello sketch e successivi caricamenti) ad un certo punto non carica più e dà errore.
La scheda è un clone geekcreit con cpu SMD
Quando la alimento con 7V esterni si accendono i LED on e L13 fissi
quando la alimento con USB il LED 13 fa 4 o 5 raffiche di lampeggi veloci poi rimane fisso

Prove effettuate:
il PC (con win7) funziona con altre 2 schede: un clone con CPU DiL e un arduino genuino uno,
stessa cosa con un altro PC con XP e IDE 1.6.0: le altre 2 schede vanno e quella incriminata no.

Ho anche provato ripetutamente la manovra col reset senza esito.
Caricando lo sketch blink mi dà questo errore:

Arduino:1.6.0 (Windows XP), Scheda:"Arduino Uno"

Lo sketch usa 1.030 byte (3%) dello spazio disponibile per i programmi. Il massimo è 32.256 byte.

Le variabili globali usano 9 byte (0%) di memoria dinamica, lasciando altri 2.039 byte liberi per le variabili locali. Il massimo è 2.048 byte.

avrdude: stk500_recv(): programmer is not responding
Problema di caricamento sulla scheda. Guarda http://www.arduino.cc/en/Guide/Troubleshooting#upload per suggerimenti

GFP:
Quando la alimento con 7V esterni si accendono i LED on e L13 fissi

Cosa intendi con "alimento con 7V esterni"? Tramite il connettore di alimentazione? Su Vin? E perché 7V?

quando la alimento con USB il LED 13 fa 4 o 5 raffiche di lampeggi veloci poi rimane fisso

Mi pare normale, inizializza la seriale su USB.

il PC (con win7) funziona con altre 2 schede: un clone con CPU DiL e un arduino genuino uno,
stessa cosa con un altro PC con XP e IDE 1.6.0: le altre 2 schede vanno e quella incriminata no.

Ti manca di provare con Windows 98. (scusa, non ho resistito... :wink: )

avrdude: stk500_recv(): programmer is not responding

Domanda: tu stai cercando di fare upload sulla scheda NON connessa a nulla? Oppure cosa c'è connesso? non è che hai qualcosa connesso sui pin D0 o D1?

Da breve ricerca con google quella scheda comunica su usb con il chip CH340; hai caricato il driver per quel chip ? (che non viene fornito con IDE di Arduino visto che non è una originale)

nid69ita:
(che non viene fornito con IDE di Arduino visto che non è una originale)

Si ci avevo pensato anche io, ma ha scritto che con un clone funziona, o almeno suppongo che "un clone con CPU DiL" (forse intendeva DIP) intendesse un clone di una UNO.

Probabilmente non lo stesso clone, se uno è smd e l'altro dip, non credo siano prodotte da stessa azienda.
Ci sono alcuni cloni che usano il CP2102

Però... ho letto male. Non carica più gli sketch... ma prima li caricava ?

nid69ita:
Probabilmente non lo stesso clone, se uno è smd e l'altro dip, non credo siano prodotte da stessa azienda.

Si ma i cloni hanno praticamente tutti lo stesso chip seriale, quindi o è rotto quello o c'è qualcosa che su quel clone specifico impedisce la comunicazione seriale ed in genere è l'uso dei pin D0 e D1 (magari ci ha messo qualcosa e non ha pensato che deve disocnnetterlo prima di fare upload).
Io ad esempio con una WeMos D1R2 che ho preso da poco mi sono ritrovato a non riuscire a caricare lo sketch perché avevo usato il pin D4 che pare usi per la seriale (nota: malimortacciloro, perché con la R2 hanno cambiato tutti i pinout rispetto alla R1 e ad Arduino?)

Vediamo che ci dice l'OP.

docdoc:
Vediamo che ci dice l'OP.

... che, fatta la domanda in data 06/06 ... è poi sparito ... ::slight_smile:

Guglielmo

Ci sono, ci sono: ho continuato il lavoro con l'altro clone con la CPU DIL 28 pin e 5 minuti fa s'è piantata anche questultima!
Ricapitolando:
l'alimentatore esterno a 7 volt, collegato alla presa coassiale, per ridurre al minimo la dissipazione degli stabilizzatori interni della scheda.
Durante il lavoro (lo ammetto, procedevo in modo empirico: modifica sketch-carica-prova) la UNO era collegata alle periferiche (che vanno a 12V) tramite un 7809 sul pin Vin, le prove successive al guasto le ho fatte con la cheda nuda alimentata via USB.

Come scrivevo prima dopo 7-8 caricamenti OK con una modifica minima dello sketch (cambio settaggio orario sul RTC) è rimasta per un pò la scritta sto caricando poi ha dato errore.

Adesso ho due bei mattoncini fermacarte con i LED on e 13 accesi fissi.

Temo che il tutto sia nato dalla maledetta interfaccia USB del PC che saltuariamente si blocca, per quello ho provato con l'altro XP.

La domanda (da 10 €) è: Sarà sufficiente ricaricare il firmware per rianimare le vittime?

Se non chiedo troppo, con quale procedura tenendo conto che per sicurezza utilizzerò il PC con XP con IDE 1.6.0 per non rischiare l'ultimo arduino genuino uno che non è neanche mio ma di mio figlio.

Se ho azzeccato la procedura allego le foto dei due cadaveri.

fai questa prova.
vai nelle impostazione dispositivi di win.
Guarda in porte com e ltp che COM hai quando attacchi i 2 cadaveri.

Può essere che vanno a prendere dei driver non suoi e che quindi il sistema non vede.
Nel caso fai destro sulla COM del cadavere,proprietà,driver,ripristina driver

A me era successo che aveva preso i driver del ch340 al posto del ftdi

Fatto li vede entrmbe:
Arduino Uno (com11)
USB-SERIAL CH340 (com15)

Provando a caricare il blink su entrambe dopo parecchio "sto caricando... "
dà questo errore:

Arduino:1.8.12 (Windows 7), Scheda:"Arduino Uno"

Lo sketch usa 924 byte (2%) dello spazio disponibile per i programmi. Il massimo è 32256 byte.
Le variabili globali usano 9 byte (0%) di memoria dinamica, lasciando altri 2039 byte liberi per le variabili locali. Il massimo è 2048 byte.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xa4
....
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xa4
avrdude: stk500_recv(): programmer is not responding
Problema di caricamento sulla scheda. Guarda http://www.arduino.cc/en/Guide/Troubleshooting#upload per suggerimenti
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xa4
....
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xa4

Questo report potrebbe essere più ricco di informazioni abilitando l'opzione
"Mostra un output dettagliato durante la compilazione"
in "File -> Impostazioni"

Ulteriore aggiornamento:
Caricato il blink sulla scheda arduino uno genuino superstite >>> OK funge

Dato che una dei cadaveri ha l'ATMEGA su zoccolo ho scambiato le CPU:

Nessuna delle due carica il programma e danno lo stesso, summenzionato, errore.

Però il programma blink precaricato sull'ATMEGA genuino, montato sulla scheda guasta, blinka.

Deduzione mia: Ho fritto sia la porta USB sia la CPU!

HELP!!!
L'unico tentativo che mi rimane è caricare il bootloader sulla CPU escludendo la porta USB.

E' possibile? con quale procedura? con quale firmware?

P.S.
A comprare altre 2 schede ci ho già fatto un pensierino.

Non ho comunque ancora capito bene. Parli di alimentatore esterno a 7 V sul coassiale e di un regolatore 7809 (che esce a 9V) sul Vin, e della USB: collegati TUTTI contemporaneamente, anche mentre facevi upload, oppure staccavi sempre tutto (almeno tutte le alimentazioni direi) prima di programmare?
Perché farlo ADESSO dopo il botto, non serve a niente. Quando programmi via USB è buona cosa in genere staccare qualsiasi alimentazione esterna (oltre a qualsiasi eventuale cose collegata ai pin D0 e D1).

GFP:
A comprare altre 2 schede ci ho già fatto un pensierino.

Altro che pensierino, dovresti aver già mandato l'ordine :wink:
E da ora piantala di paciugare con le connessioni ed alimentazioni "miste", e non toccare l'Arduino di tuo figlio! :smiley:

OOpppsssss

Avevo attaccato l'alimentazione a 12v con relativo ruduttore a 9V + cavetto USB

Avevo letto da qualche parte che la scheda gestiva in automatico le alimentazioni...

Evidentemente UNA ALLA VOLTA!

Grazie a tutti per l'aiuto

Eh già.....hai fritto todo
Era successo anche a me con un clone facendo come hai fatto tu