Plötzlich mag er nicht mehr und spuckt folgenden Text aus:
1
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xfc
2
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xe0
3
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x1c
4
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
5
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xfc
6
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
7
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0xe0
8
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xe0
9
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x1c
10
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
11
12
avrdude done. Thank you.
13
14
Process returned 1 (0x1) execution time : 1.334 s
15
Press ENTER to continue.
Ich habe dann den Parametersatz um die -F-Option – kein Signaturtest –
erweitert und konnte damit noch einmal flashen, aber seither geht nichts
mehr. Das Programm de Controllers funktioniert aber weiterhin.
Was ist da los?
Kabelbruch, oder dein Programmer kommuniziert zu schnell.
Mach einen Gegentest mit einem anderen Mikrocontroller oder einem
anderen Programmieradapter.
Probiere den Parameter -B20 oder ganz extrem -B2000
Stefan F. schrieb:> Probiere den Parameter -B20 oder ganz extrem -B2000
Seine Avrdude-Kommandozeile spricht ja mit dem Bootloader auf dem Chip,
da wird das nicht helfen.
Und verfused wird der AVR auch nicht sein, der Bootloader erlaubt m.W.
kein Ändern der fuses?
Εrnst B. schrieb:> Seine Avrdude-Kommandozeile spricht ja mit dem Bootloader auf dem Chip,> da wird das nicht helfen.
Ja dann hilft das nicht. Ich war von einem ISP Adapter ausgegangen.
Die -B-Option ändert mit 20 und 2000 nichts.
Kabelbruch: die Ausgaben des Controllers kann ich über GtkTerm lesen und
Eingaben machen – das funktioniert alles einwandfrei.
Anderer Controller: auf einen anderen Nano kann ich problemlos flashen.
Das Programm läuft auch an, bleibt dann aber hängen, weil es die
Peripherie nicht findet.
Nur flashen will er nicht.
Halte mal den Reset Knopf fest und lasse ihn erst in dem Moment los, wo
avrdude mit dem Bootloader kommunizieren will.
Und probiere trotzdem mal ein anderes USB Kabel. Beim Flashen braucht
der AVR eine stabilere Versorgungsspannung, als im normalen betrieb.
2 Gründe wieso ich den Fehler habe.
1. Falscher Bootloader. Ich muss bei meinen alten Teilen immer
Nano-(OLD) einstellen.
2. Ich muss die MHZ-Zahl immer auf 1 (nicht 4) stellen.
Dann rennt die IDE wie ein Hase.
Ich gehe bei meiner Aussage von Fertigen-China-Clones aus. !!!!
Stefan F. schrieb:> Und probiere trotzdem mal ein anderes USB Kabel.
Damit gehts… So eine Scheiße. Ich hatte schon ähnliche Probleme mit
einem USB-A-Stecker, mit dem ich das Ding an eine Powerbank anschließe.
Es zieht 2,3 A aus der PB und es gab immer mal wieder Meßfehler von den
beiden DS18B20. Es stellte sich heraus, dass sporadisch an diesem
Stecker so viel Spannung abfiel, dass die Sensoren mit parasitärer
Versorgung nicht mehr wollten.
Ich habe dann einfach ein für 2,4 A spezifiziertes USB-Ladekabel
geschlachtet und seither funktionierts. Eine Software-Ertüchtigung, die
bei der nächsten Messung nach Fehler die Last abschaltet, kam als
Notanker dazu.
Taucher schrieb:> Damit gehts… So eine Scheiße.
hm. Bei den Stress den man aktuell mit Billig-Kabeln hat, sollte man ein
Kabeltester bauen. Ich denke das wird sich lohnen. Besonders wenn er mit
Akku läuft. Dann kann man die Strippen schon im 1-Euro-Markt testen. ;)
Das Kabel wars nicht, dass es ging, war wohl Zufall.
Wenn den Reset-Knopf gedrückt halte, avrdude starte und dann Reset los
lasse, dann scheint es zuverlässig zu funktionieren.
Wie erklärt man sich das? Hat der USB-Chip eine Macke, oder der 328?
Taucher schrieb:> Wie erklärt man sich das?
Der Avrdude "wackelt" beim Starten kurz mit einer der Zusatz-Leitungen
(DTR?) der RS232-Schnittstelle. Das löst einen Reset des M328 aus, der
startet seinen Bootloader und los gehts.
Statt des automatischen Resets machst du das jetzt per Hand mit flinken
Fingern.
Schau im Schaltplan deines Moduls nach wie der Reset verschaltet ist,
das kann z.B. über einen Koppelkondensator oder Transistor laufen, da
kann auch was kaputt sein.
Oder hast du den Reset-Pin extern beschaltet? Wenn da z.B. ein
Kondensator dran hängt, reicht der kurze Puls nicht, den leer zu
bekommen, und es gibt keinen Reset.
Taucher schrieb:> Wenn den Reset-Knopf gedrückt halte, avrdude starte und dann Reset los> lasse, dann scheint es zuverlässig zu funktionieren.
Machs wie ich.
Kaufe dir ein USB-HUB mit Netzteil und Schalter pro Port. Wenn ich
Stress habe, Port aus 2 Sek. warten, Port an. 2.0er bekommst du aktuell
für so 15 Euro.
Die Fummelei mit den Resettaster mache ich nicht. Das ist mir zu
frickelig.
1. Das ist sichererer Weil es dein PC-Port schützt.
2. Bequemer (Ich schalte den Port aus wenn ich nicht am Projekt arbeite
und gut ist.;)
Εrnst B. schrieb:> Der Avrdude "wackelt" beim Starten kurz mit einer der Zusatz-Leitungen> (DTR?) der RS232-Schnittstelle. Das löst einen Reset des M328 aus, der> startet seinen Bootloader und los gehts.> Statt des automatischen Resets machst du das jetzt per Hand mit flinken> Fingern.
Ich kenne das Innenleben des Bootladers und den Trick, wie er über USB
gestartet wird.
> Schau im Schaltplan deines Moduls nach wie der Reset verschaltet ist,> das kann z.B. über einen Koppelkondensator oder Transistor laufen, da> kann auch was kaputt sein.
Mein Nano hat den CH340 USB-Chip. Dessen DTR-Ausgang ist einfach
zwischen dem 10 k Pullup und dem Reset-Taster mit 100 nF auf den
Reset-Pin des 328 geklemmt.
> Oder hast du den Reset-Pin extern beschaltet? Wenn da z.B. ein> Kondensator dran hängt, reicht der kurze Puls nicht, den leer zu> bekommen, und es gibt keinen Reset.
Nein, dort hängt sonst nichts dran. Es gibt also nur zwei Möglichkeiten:
entweder hat der CH340 was, oder über den USB kommt nur manchmal der
DTR.
Es wird wohl das Einfachste sein, parallel zum Reset-Knopf des Nano
einen kleinen Reedkontakt zu hängen, dass man von außen mit einem
Magneten durchs Gehäuse resetten kann.
Gibt es unter Linux eine Möglichkeit, mit einfachen Mitteln DTR auf USB
"wackeln" zu lassen, damit man nachsehen kann, ob aus dem DTR-Pin des
CH340 ein Signal kommt?
Taucher schrieb:> Gibt es unter Linux eine Möglichkeit, mit einfachen Mitteln DTR auf USB> "wackeln" zu lassen, damit man nachsehen kann, ob aus dem DTR-Pin des> CH340 ein Signal kommt?
Das Hammer Terminal hat dafür einen Button.
http://der-hammer.info/pages/terminal.html
Taucher schrieb:> Gibt es unter Linux eine Möglichkeit, mit einfachen Mitteln DTR auf USB> "wackeln" zu lassen, damit man nachsehen kann, ob aus dem DTR-Pin des> CH340 ein Signal kommt?
gtkterm kann das scheinbar auch:
1
Description: simple GTK+ serial port terminal
2
gtkterm is a simple GTK+ terminal used to communicate with the serial port.
3
4
Its features :
5
6
* Serial port terminal window
7
* Serial port setup (speed, parity, bits, stopbits, flow control)
8
* Using the termios API
9
* Possible to send a file (only RAW data, no protocol)
10
* End of line delay while sending a file
11
* Special character wait before next line while sending a file
12
* Possible to toggle control lines manually (DTR, CTS)
13
* Also reads the state of control lines (RTS, CD, DSR, RI)
Steve van de Grens schrieb:> Das Hammer Terminal hat dafür einen Button.
hterm kennt keine /dev/ttyUSBn – aber daran hängt mein Nano.
Alexander S. schrieb:> gtkterm kann das scheinbar auch
Ja, mit F7 lässt sich DTR toggeln – man lernt nicht aus…
Taucher schrieb:> Alexander S. schrieb:>> gtkterm kann das scheinbar auch>> Ja, mit F7 lässt sich DTR toggeln – man lernt nicht aus…
Ja, und unten rechts wird der Zustand angezeigt. Hast Du aber
wahrscheinlich selbst schon gesehen.
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten