Moin, ich habe hier ein ArduinoMega2560 mit aufgestecktem Ethernet Shield. Aus mir unerfindlichen Gründen lies sich das Board nicht per Bootloader programmieren, also habe ich es mit einem AVR ISP mkII gebrannt, was auch problemlos funktioniert. Dadurch ist natürlich der Bootloader futsch. Da sich mein Rechner inzwischen an das Arduinoboard am USB-Anschluss "gewöhnt" hat (Windows... ;)), habe ich den Bootloader aus der IDE heraus wieder installiert. Ein darauffolgender Programmierversuch per Bootloader funktionierte auch problemlos. Ein weiterer leider nicht. Erst nachdem ich wieder den Bootloader per ISP installiert habe. Aber auch dann: Ein Mal per Bootloader, dann per ISP. Laut der gefundenen Beträge im Internet sollen die Lockbis mit dem Wert 0xCF beschrieben sein - was sie auch sind. Kann mir jemand den einen oder anderen Hinweis geben, was da schief läuft und wie ich es beheben kann? Jedes Mal das Ethernet-Shield abnehmen und den ISP anstecken nervt. Vielen Dank im Voraus! Rahul
Öhm...
Arduino Umgebung:
Ja, der Bootloader muss per ISP geladen werden.
Dabei werden auch die Fuses richtig gesetzt.
Danach sollte das weitere Laden über USB möglich sein.
Immer wieder. Ca. 10000 mal.
Per Seriellen Port den Bootloader zu deaktivieren ist, glaube ich,
unmöglich.
Zumindest sehr schwer möglich. Wohl nicht aus Versehen
>ich habe hier ein ArduinoMega2560 mit aufgestecktem Ethernet Shield.
Ich auch.
Keine Probleme damit. (zumindest nicht solche)
Wahrscheinlich ist der Bootloader nicht geschützt. Lockbit. Sicher das dein Progrqamm nicht nur Quark anzeigt ? Setz die Fuses mal erneut mit avrdude! Gruss Trollo
@rahul ich weiß jetzt nicht wie die Anbindung beim Arduino aussieht, aber kann es sein das dein Programm die Kommunikation der seriellen Schnittstelle zum Bootloader stört? So wie du es beschreibst geht der Bootloader nur solange dein Programm noch nicht drauf ist. Sascha
So gerade noch mal ausprobiert: Bootloader installiert (L-LED blinkt). Applikation per USB installiert: geht Applikation versucht ein zweites Mal per USB zu installieren: timeout. Also "zerschieße" ich mir den Bootloader wohl irgendwie. Nur wie kann ich das verhindern?
Rahul Der trollige schrieb: > So gerade noch mal ausprobiert: > Bootloader installiert (L-LED blinkt). > Applikation per USB installiert: geht > Applikation versucht ein zweites Mal per USB zu installieren: timeout. > Also "zerschieße" ich mir den Bootloader wohl irgendwie. das geht eigentlich nicht, denn der Bootloader kann sich nicht selbst überschreiben. Verwendest du die serielle Schnittstelle an PE0/PE1 oder die Pins an sich? Sascha
Sascha Weber schrieb: > Verwendest du die serielle Schnittstelle an PE0/PE1 oder > die Pins an sich? ichz benutze die USB-Schnittstelle des ARDUINO Mega 2560, an der der ATmega16U2 hängt.
Mach doch mal einen simplen Versuch: Nachdem der Bootlader "zerschossen wurde", nimmst du einen ISP Programmer und liest das Flash aus. Dann kannst du schnell sehen, ob der Lader noch intakt ist. Und du liest die Fuses aus und kontrollierst, ob der Bootlader noch aktiv ist.
Rahul Der trollige schrieb: > Also "zerschieße" ich mir den Bootloader wohl irgendwie. Vielleicht zerschießt dein laufendes Programm den Bootloader, indem es wild im Flash rumfuhrwerkt?
Geht eventuell der automatische reset nicht? Drück mal den Knopf kurz nachdem die uploading... Meldung erscheint
Ich kenne mich mit Arduino nicht aus. Könnte es folgendes problem sein?: Ohne Programm läuft der Bootloader ständig. Er wartet beliebig lange darauf, dass Du ein Programm hoch lädst. Mit Programm wartet der Bootloader (nach dem Reset) nur für einen kurzen Moment. Du versuchst zu spät, das Programm hochzuladen. Lösungsansatz: Reset Taste drücken und sofort danach das Hochladen starten. Eventuell sogar anders herum: Erst das Hochladen (PC seitig) starten und dann den Reset Knopf drücken.
Kann es sein, dass du erst den Bootloader über SPI auf deinen Arduino überträgst, dann dein eigentliches Programm wieder per SPI überträgst (und damit deinen Bootloader überschreibst)?
Rahul Der trollige schrieb: > Kann mir jemand den einen oder anderen Hinweis geben, was da schief > läuft und wie ich es beheben kann? Hast Du eventuell irgendwas an RX/TX (Pin-0/1) angeschlossen? Im übrigen haben viele MEGA-Bootloader einen Programmfehler: Sobald Dein HEX-File drei Ausrufungszeichen in Folge enthält (meistens in einem String), funktioniert der Bootloader-Upload (an MEGA-Boards mit diesem fehlerhaften Bootloader) nicht mehr, sondern führt zu einem Timeout. Sozusagen ein Lockout von Grammatik-Koryphäen, denen weder ein Ausrufungszeichen noch zwei Ausrufungszeichen genug sind, sondern die erst drei (oder mehr) Ausrufungszeichen hintereinander ballern müssen, damit es richtig knallt.
Zur Eingrenzung des Fehlers wäre es imho sinnvoll, mal meine Vorschlag von weiter oben an zu gehen. Momentan stochern hier alle mit der Stange im Nebel. Wird der Bootlader überschrieben? Wird er nicht aktiviert? Geh doch mal systematisch vor!
So, dann melde ich mich mal wieder. Da der zerschossene Bootloader nur eine Vermutung war, habe ich mal eine andere Anwendung installiert (blink.ino). Das ging auch einfach so. Die konnte ich mehrfach installieren (Blinkfrequenz variiert, um festzustellen, ob die Installation erfolgreich war). Dann habe ich es mit aufgestecktem Ethernet-Shield probiert und da hakte es dann. Vielleicht besorge ich mir jetzt noch ein originales Ethernet-Shield, denn manche "Nachbauten" sind offensichtlich nicht so kompatibel wie sie sein sollten... Danke für die Hinweise.
Rahul Der trollige schrieb: > Dann habe ich es mit aufgestecktem Ethernet-Shield probiert und da hakte > es dann. Bootloader mit eingesteckter SD-Karte programmiert? Programmierung verifiziert? Bei eingesteckter SD-Karte funktioniert nämlich die Programmierung über ISP nicht sicher. LG, Sebastian
Rahul Der trollige schrieb: > mal eine andere Anwendung installiert (blink.ino). > Das ging auch einfach so. > Die konnte ich mehrfach installieren (Blinkfrequenz variiert, um > festzustellen, ob die Installation erfolgreich war). > Dann habe ich es mit aufgestecktem Ethernet-Shield probiert und da hakte > es dann. Derselbe Blink-Sketch, der sich ohne aufgestecktes Ethernet-Shield hochladen läßt, läßt sich mit aufgestecktem Ethernet-Shield dann nicht mehr hochladen? Da das Ethernet-Shield die serielle Schnittstelle an Pin-0/1 gar nicht anfaßt, kann es eigentlich nur mit dem gesteckten Shield zu tun haben. In manchen Fällen sind die Stiftleisten am Shield ein bisschen zu kurz, da würde ich mal schauen, ob vielleicht die Lötseite des Shields auf der USB-Buchse des Boards aufsitzt und einen Kurzschluß verursacht. Und dann ggf. das Shield oberhalb der USB-Buchse einen halben Millimeter aus der Headerleiste herausziehen, so dass es den Kurzschluß mit der USB-Buchse des Boards nicht mehr gibt.
Timer-Interrupt plattgemacht? Hatten neulich gleich nebenan darüber geplaudert: Beitrag "Re: Danneggers Entprellroutine im AVR benutzen"
So, Problem behoben: Neues (originales) Ethernet-Sheild gekauft und aufgesteckt, Netzteil angeschlossen: alles gut! Der Unterschied zum alten Ethernet-Shield ist, dass das China-Ding schief in den Buchsenleisten steckt und auch noch mies verlötet ist - das absolute Gegenteil zum originalen Shield, mit des keine Pobleme gibt. Und wieder gilt: Wer billig kauft, kauft zweimal.
Muss den Fred mal wieder rauskramen, da ich vor nahezu identischem Problem stand und beim Lesen just die Lösung fand: Aufbau: Breadboard mit Mega168 und ext. 16 MHZ Oszillator (im Arduino ein Diecimilia mit M168 ausgewählt) und FTDI-Adapter für den seriellen Upload und einen USBASP ISP zum flashen über MISO/MOSI. 1. naktem Mega168 mittels Arduino und USBASP ISP bzw. avrdude den Bootloader spendiert 2. Status LED an Digitalpin 13 blinkt (ergo Bootloader läuft) 3. Testprogramm mit seriellem FTDI hochgeladen (funktioniert) 4. Testprogramm erneut mit FTDI hochladen (keine serielle Verbindung zur MCU mehr möglich) 5. ergo Bootloader gelöscht Habe den Bootloader dann nochmal ohne Arduino direkt über avrdude geflasht und die Fueses und Lockbits nochmal mit den entsprechenden Werten gesetzt. Die Problematik blieb aber weiterhin bestehen. Danach bin ich, aufgrund eines Beitrages hier zur Resetverzögerung, meine Hardware nochmals durchgegangen. Ich hatte einen 0,1 nF Kerko in der Resetleitung. Als ich diesen mit einem 100 nF Kerko ersetzt habe, funktionierten fortan alle seriellen Uploads und der Bootloader blieb heile.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.