Hallo habe ein custom Atmega2560 board und muss den Bootloader drauf haben damit ich mit stk500 über USB->RS232 die CPU programmieren kann. Ich habe es mit einem UNO Board geschafft den Bootloader zu brennen. Habe dazu dies verwendet http://www.gammon.com.au/bootloader. Es funktioniert tatsächlich, so dass ich über stk500 ein mal den 2560'er flashen kann aber nur ein mal. Es scheint als ob der bootsektor überschrieben wird. Kennt jemand eine Lösung? Danke
Du musst deinem ISP-Programmer (also dem STK500) auch sagen, dass es beim Chip-Erase den Bootloader nicht löschen soll. Sonst überschreibst du den nämlich tatsächlich.
Das STK500 ist normalerweise ein ISP Programmer, der keinen Bootloader benötigt und somit den gesamten Flash neu beschreibt. Bist du dir sicher, dass du den richtigen COM Port am STK verwendest und die RX/TX Pins entsprechend verbunden hast ?
Jürgen G. schrieb: > Es funktioniert tatsächlich, so dass ich über stk500 ein mal den 2560'er > flashen kann aber nur ein mal. Es scheint als ob der bootsektor > überschrieben wird. > > Kennt jemand eine Lösung? Ja! Den stk500, nach dem Bootloader schreiben, in die Schublade legen! Danach einen seriell Adapter verwenden. (natürlich nicht vergessen, die Bootloaderfuses zu setzen.)
Vielen Dank für die schnellen Antworten! Ich muss mich korrigieren. Ich verwende einen USB to Serial Adapter. https://shop.openenergymonitor.com/programmer-usb-to-serial-uart/ Ich bin mir nicht sicher ob die Bezeichung STK500 stimmt. sorry. Ich verwende u.a. auch die arduino IDE. In der IDE kann ich nicht angeben den Bootloader nicht zu überschreiben. Oder wenn ich direkt über avrdude downloade "z.B. avrdude –c stk500v1 –P\\.\COM4 –p m2560 –U flash:w:filename.hex" dann sollte ja auch nichts passieren mit dem Bootloader. Es müsste doch aber auch möglich sein mit den lock bits den Bootloader resistent im Chip zu belassen, oder? Der Grund: Das 2560'er Board ist über eine serielle Schnittstelle mit einem Rasperry PI verbunden und auf diesem kann ich avrdude remote ausführen. Schlussendlich gehts um remote firmware update.
Angehängte Dateien:
-
bl.png
190 KB
welche Lockbits muss ich setzten damit der Bootloader drin bleibt?
Jürgen G. schrieb: > Es funktioniert tatsächlich, so dass ich über stk500 ein mal den 2560'er > flashen kann aber nur ein mal. Es scheint als ob der bootsektor > überschrieben wird. Es scheint nur so. Du hast vergessen, in den Fusebits das Bootloaderreset zu aktivieren. Solange die Applikation noch leer ist, merkst Du das nur nicht.
aha.. d.h. ich muss ich aktivieren: Fusebit BOOTRST=0 ->Was macht das genau? und welche(s) Lock Fusebit muss ich setzen?? Bootloader protection mode 1,2,3 oder 4?
Ich habe es ausgetestet mit BOOTRST aktivieren und dann lock bits auf 0x2F zu stellen. Leider immer noch das Geiche. Der Bootloader wird überschrieben nach dem ersten Mal App schreiben. Hier der Output von Avrdude beim schreiben der fuses:
1 | c:\Program Files (x86)\Arduino\hardware\tools\avr\bin>avrdude -p m2560 -c usbtiny -U hfuse:w:0xd0:m -U lock:w:0x2f:m |
2 | |
3 | avrdude: AVR device initialized and ready to accept instructions |
4 | |
5 | Reading | ################################################## | 100% 0.01s |
6 | |
7 | avrdude: Device signature = 0x1e9801 (probably m2560) |
8 | avrdude: reading input file "0xd0" |
9 | avrdude: writing hfuse (1 bytes): |
10 | |
11 | Writing | ################################################## | 100% 0.01s |
12 | |
13 | avrdude: 1 bytes of hfuse written |
14 | avrdude: verifying hfuse memory against 0xd0: |
15 | avrdude: load data hfuse data from input file 0xd0: |
16 | avrdude: input file 0xd0 contains 1 bytes |
17 | avrdude: reading on-chip hfuse data: |
18 | |
19 | Reading | ################################################## | 100% 0.02s |
20 | |
21 | avrdude: verifying ... |
22 | avrdude: 1 bytes of hfuse verified |
23 | avrdude: reading input file "0x2f" |
24 | avrdude: writing lock (1 bytes): |
25 | |
26 | Writing | ################################################## | 100% -0.00s |
27 | |
28 | avrdude: 1 bytes of lock written |
29 | avrdude: verifying lock memory against 0x2f: |
30 | avrdude: load data lock data from input file 0x2f: |
31 | avrdude: input file 0x2f contains 1 bytes |
32 | avrdude: reading on-chip lock data: |
33 | |
34 | Reading | ################################################## | 100% 0.02s |
35 | |
36 | avrdude: verifying ... |
37 | avrdude: 1 bytes of lock verified |
38 | |
39 | avrdude: safemode: Fuses OK (E:FD, H:D0, L:FF) |
40 | |
41 | avrdude done. Thank you. |
So ganz nebenbei... ein Bootloader kann sich in einem flashbasierten system nicht selbst ueberschreiben. Das geht nur in einem Systeme, wo der Code in RAM ausgefuehrt werden kann.
Richtige Fuse Bootloadergröße? wenn der Bootloader 2KB hat und nur 1KB eingestellt ist könnte der beim flashen des programms überschrieben werden.
Jürgen G. schrieb: > avrdude -p m2560 -c usbtiny -U hfuse:w:0xd0:m -U lock:w:0x2f:m Seit wann kann man denn über den Bootlader die Lockbits und Fusebits schreiben? Ich würde ja mal behaupten, dass Du den Bootloader immernoch nicht nutzt. Was du da machst ist ISP, das hat nichts mit dem Bootloader zu tun. Nutze den doch mal und dann sagst du uns, ob der Bootloader dann immernoch überschrieben wurde. Wie schon geschrieben: Arduino F. schrieb: > Den stk500, nach dem Bootloader schreiben, in die Schublade legen! > Danach einen seriell Adapter verwenden. Du müsstest nun im Prinzip nur noch soetwas: https://www.intos.de/media/image/thumbnail/0_444_0_720x600.jpg oder so etwas: http://www.ftdichip.com/Images/TTL-232R1.jpg verwenden. Werner
Flashen über ISP beginnt immer mit einem vollständigen Löschen des Flash Speichers. Damit ist der Bootloader dann weg. Geht bei AVR's nicht anders.
Vielen Dank für all Eure Informationen. Ihr habt mit aber jetzt etwas abgehängt... Kurz nochmals damit ich Euch richtig verstehe: Bootloader ist die Software über welche ich einfach über TX und RX Pins des Atmega2560 neue App FW flashen kann. Mit dem USB zu Serial converter kann ich z.B. mit arduino oder avrdude direkt FW auf die CPU laden. ISP ist die Schnittstelle (SPI) wo ich den Bootloader Code in den CPU Flash schreiben kann. Die Fuse Bits kann ich mit avrdude über ISP programmieren -------------- Ich kann den Bootloader auf die CPU brennen, das funktioniert sehr gut. Die Fuse bits habe ich dann so gesetzt, dass die Bootloader Sektion gesperrt ist (Applications FW kann Bootloader nicht überschreiben), die Bootloadergrösse auf Maximum 4096 gesetzt ist, und BOOTRST aktiviert ist. Danach kann ich über die serielle Schnittstelle meine Applikation auf die CPU brennen. Soweit so gut. Aber ich kann nur einmal dies machen. Habe ich einen Überlegungsfehler? Vielen Dank!
Jürgen G. schrieb: > Aber ich kann nur einmal dies machen. Wenn du soweit alles richtig gemacht hast, und danach sieht es aus. (kann ich leider nicht überprüfen) Dann fehlt bestimmt nur noch die richtige Reset Beschaltung. Der Reset deines µC braucht dafür einen Pullup, ca 10K sollten ok sein. Und einen 100nF Kondensator zwischen DTR deines Adapters und Reset des µC Alternativ: Im richtigen Moment Reset drücken, wenn Reset Taster vorhanden.
Vielen Dank. Nein Reset funktioniert tadellos. Ich kann ja die App FW auf die CPU brennen. Wenn ein Reset vorhanden wäre würde avrdude nicht brennen können.
Jürgen G. schrieb: > Wenn ein Reset vorhanden wäre würde avrdude nicht brennen > können. Das ist ein Irrtum! Bedenke: Ohne Reset kommt der Bootloader gar nicht ins Spiel. Das erste Mal klappts nur, weil noch keine Anwendung auf dem µC ist. Die Eingangsfrage > Bootloader für ATmega 2560 wird immer überschrieben ist also falsch Sie müsste lauten: > Warum kommt mein Bootloader nicht ins Spiel? Antwort: Es wird vor dem Upload kein Reset ausgeführt.
Angehängte Dateien:
-
image.png
150 KB
Ich habe kurz die Webseite überflogen - da steht was von 8192byte für den Bootloader Wie groß ist der Bootloader denn? Gruß Sven
Angehängte Dateien:
-
Unbenannt.JPG
91 KB
Danke das macht Sinn aber ich habe eine saubere Reset-Schaltung. Gem. Anhang
Du verstehst miss. Folgendes: Der Chip wird eingeschaltet und springt in den Bootloader. Der Bootloader wartet N ms auf ein Update und springt dann in die eigentliche Firmware. Wenn keine Firmware vorhanden ist, wartet er ewig. Wie bekommst du den Chip wieder dazu, auf Updates zu warten? Indem du ihn manuell resettest!
Jürgen G. schrieb: > aber ich habe eine saubere Reset-Schaltung. > Gem. Anhang Hast du nicht! Der Kondensator an GND ist falsch, wenn du den Bootloader nutzen willst. Dann muss der Kondensator zwischen Reset und DTR deines USB Seriell Adapters. Wenn du den Kondensator "so" behalten willst, wirst du den Reset mit einem Transistor, oder zufuß, betätigen müssen. Glaube mir! Glaube mir! Glaube mir! Und wenn nicht, dann möchte ich gerne Gegenanzeigen sehen/lesen/hören.
Ja du hast recht!!! Ich sehe den Wald lauter Bäume nicht mehr.morgen teste ich das aus
Angehängte Dateien:
-
Unbenannt2.png
39 KB -
Unbenannt.png
400 KB
Moment.. habe ich selber übersehen. Ich habe ja ein C zw. DTR und Reset. Mein FTDI USB-Serial Adater würde ja sonst nocht funktionieren. Das RC Glied ist nur für den Startup des Boards damit zuerst die Speisespannung hochkommen kann und dann der Reset.
2 gleiche Kondensatoren gegeneinander. Das heißt, der Reset Pegel sinkt nur auf 50%. Oder noch etwas weniger, wegen dem Pullup. Sagen wir mal 60% ... Ich glaube nicht, dass ein 5V ATMega bei 3V in den Reset geht. Habe aber jetzt auch nicht das Datenblatt daraufhin überprüft, das überlasse ich dir. Nachtrag: Habe gerade den Schaltplan des Arduino Mega überprüft. Da ist es wie in deinem Plan. Und das tuts schließlich... Nunja... So kanns kommen.
Stefan U. schrieb: > Flashen über ISP beginnt immer mit einem vollständigen Löschen des Flash > Speichers. Damit ist der Bootloader dann weg. Geht bei AVR's nicht > anders. in den Compiling Options der Arduino-IDE ist dann sowas wie "LDFLAGS += -Wl,--section-start=.text=$(BOOTLOADER_ADDRESS)" mit drin. Das könnte das doch umgehen?
Nein, ich denke das hat nichts mit den Sektionen zu tun. Vor dem Flashen des Programms wird immer ein Löschbefehl abgesetzt. Und der löscht den ganzen Speicher. man hat nur die Wahl, ob auch das EEprom gelöscht werden soll, oder nicht.
Hmmm okay, muss zugeben das ist mir nur so neu, das mir das entweder nie aufgefallen ist oder die Arduino IDE da sie alle Bootloader dabei hat den gleich in eins mitschreibt.. Da gibt es die Option "upload using Programmer".. ISP benutze ich bis auf wenige Ausnahmen nur zum Bootloader Flaschen.
Arduino F. schrieb: > Habe gerade den Schaltplan des Arduino Mega überprüft. Da ist es wie in > deinem Plan. > Und das tuts schließlich... In meinem Schaltplan hat der Kondensator nach GND aber nur 22p.
Hubert G. schrieb: > In meinem Schaltplan hat der Kondensator nach GND aber nur 22p. Viel plausibler! https://www.arduino.cc/en/uploads/Main/arduino-mega-schematic.pdf 100nF https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-sch.pdf 22pF :) So kann Fortschritt auch aussehen :) Und ich dachte schon ich spinne... (wobei, das würde mich auch nicht sehr wundern)
Ich habe die Reset Schaltung temporär so verändert, dass ich nur ein 0.1u C zwischen DTR des FTDI Programmers und dem Reset Pin habe. C18 gegen GND ist jetzt komplett weg. Klar, power up Reset funktioniert zZ nur manuell. Aber so kann ausgeschlossen werden, dass das Problem beim Reset liegt. Ich bin mir ziemlich sicher, dass es an den Fuse Bits liegt. Den Bootloader flashe ich mit Gammon's Sketch auf die CPU- siehe Output unten. Nur einmal aber kann ich danach über FTDI meine Applikation hochladen. Eine logische Erklärung wäre also dass der Bootloader überschrieben wird. Gemäss Output von Gammon's Sketch hat der Bootloader eine Grösse von 8192Bytes. Fie Fuse bits werden wie folgt gesetzt (gem. Output Gammon Sketch): - "Boot Sector Flash Size" = 4096 Words. Wenn 1 Word = 2 Bytes dann passts - Start Adresse ist dann bei 1F000. - Lock bits: "Boot Loader Protection Mode2: SPM prohibited in Boot Loader Section" -> SPM heisst Storage Programm Memory, Einstellung scheint ok - Fuse Bit "BOOTRST" ist aktiviert, das passt auch soweit. Output von Gammons Sketch mit welchem ich den BL flashe:
1 | Erasing chip ... |
2 | Writing bootloader ... |
3 | Committing page starting at 0x3E000 |
4 | Committing page starting at 0x3E100 |
5 | Committing page starting at 0x3E200 |
6 | Committing page starting at 0x3E300 |
7 | Committing page starting at 0x3E400 |
8 | Committing page starting at 0x3E500 |
9 | Committing page starting at 0x3E600 |
10 | Committing page starting at 0x3E700 |
11 | Committing page starting at 0x3E800 |
12 | Committing page starting at 0x3E900 |
13 | Committing page starting at 0x3EA00 |
14 | Committing page starting at 0x3EB00 |
15 | Committing page starting at 0x3EC00 |
16 | Committing page starting at 0x3ED00 |
17 | Committing page starting at 0x3EE00 |
18 | Committing page starting at 0x3EF00 |
19 | Committing page starting at 0x3F000 |
20 | Committing page starting at 0x3F100 |
21 | Committing page starting at 0x3F200 |
22 | Committing page starting at 0x3F300 |
23 | Committing page starting at 0x3F400 |
24 | Committing page starting at 0x3F500 |
25 | Committing page starting at 0x3F600 |
26 | Committing page starting at 0x3F700 |
27 | Committing page starting at 0x3F800 |
28 | Committing page starting at 0x3F900 |
29 | Committing page starting at 0x3FA00 |
30 | Committing page starting at 0x3FB00 |
31 | Committing page starting at 0x3FC00 |
32 | Committing page starting at 0x3FD00 |
33 | Written. |
34 | Verifying ... |
35 | No errors found. |
36 | Writing fuses ... |
37 | LFuse = 0xFF |
38 | HFuse = 0xD8 |
39 | EFuse = 0xFD |
40 | Lock byte = 0xEF |
41 | Clock calibration = 0x9E |
42 | Done. |
43 | Programming mode off. |
44 | Type 'C' when ready to continue with another chip ... |
Was mir aber auffällt ist der Beginn wo geschrieben wir bei 0x3E00. Müsste das nicht 1F000 (gemäss Fuse bits) sein?
Jürgen G. schrieb: > Was mir aber auffällt ist der Beginn wo geschrieben wir bei 0x3E00. > Müsste das nicht 1F000 (gemäss Fuse bits) sein? 1f000*2 == 3e000
Ich denke da steht doch die Ursache: Hfuse muss doch mal 0xD0 sein damit der Bootloader laufen kann. Hast Du auch oben mit avrdude gefused. Aber die Bootloader Ausgabe sagt jetzt auf einmal 0xD8 ???? Gruß Sven Ps: Was gibt denn avrdude nach dem Upload mit dem Bootloader über die Fuses aus??? (Nur Auslesen )
:
Bearbeitet durch User
Danke Sven aber der Unterschied 0xD0 zu 0xD8 im hfuse byte ist nur "Preserve EEPROM memory through the Chip Erase cycle". Das kann es nicht sein. Das ist nicht der Flash speicher.
Hi Wenn du über ISP programmieren kannst, wozu brauchst du eigentlich dieses Bottloadergedödel? MfG Spess
Und warum machst du dann nicht "jedes" Update remote?
Der Flash Speicher ist 16 bit breit. Manche Programme zählen die Adressen wie der AVR selbst so: Adr Wert 0x0000 = 0xBBAA 0x0001 = 0xDDCC 0x0002 = 0xFFEE Deswegen kann der AVR mit seinem 16bit Programmzähler 128kB Programme ausführen. Nur der ATmega2560 hat einen ungewöhnlich großen Programmzähler mit 17 Bits, was bei der Programmierung mitunter besonder berücksichtigt werden muss. Manche Programme zählen jedoch stattdessen die Bytes: 0x0000 = 0xAA 0x0001 = 0xBB 0x0002 = 0xCC 0x0003 = 0xDD 0x0004 = 0xEE 0x0005 = 0xFF
Jürgen G. schrieb: > Danke Sven aber der Unterschied 0xD0 zu 0xD8 im hfuse byte ist nur > "Preserve EEPROM memory through the Chip Erase cycle". Das kann es nicht > sein. Das ist nicht der Flash speicher. Entschuldigung, da hast Du natürlich vollkommen recht. Damit sind die Fuse Einstellungen also als Fehler erstmal ausgeschlossen. Gruß Sven
Dann bleibt die Frage: Wird beim öffnen der seriellen Schnittstelle ein Reset ausgelöst? Wenn nein: Dann kommt der Bootloader auch nicht an die Reihe. Wenn ja: Woanders suchen.
Ja der reset wird ausgeführt. Erst deswegen kann ich mit dem ftdi adapter die app laden.
Jürgen G schrieb: > Erst deswegen kann ich mit dem ftdi > adapter die app laden. Ich dachte das funktioniert nicht... Beim 2ten mal... Warum es beim ersten mal, auch ohne Reset, funktioniert, habe ich doch schon erklärt, oder?
Reset funktioniert perfekt! Geprüft mit Oszi. Habe sogar das C grösser gemacht, so dass das reset Signal noch länger ansteht (C zwischen FTDi und Reset). Aber das macht keinen Unterschied. Mein FTDI Programmier funktioniert an einem Arduino UNO perfekt.
Sapperlot W. schrieb: > So ganz nebenbei... ein Bootloader kann sich in einem flashbasierten > system nicht selbst ueberschreiben. Das geht nur in einem Systeme, wo > der Code in RAM ausgefuehrt werden kann. Unsinn. Natürlich kann sich ein Bootloader bei den AVR8 auch selbst überschreiben. Und wenn er kleiner als eine Flashpage ist, braucht er nichtmal für die Daten (also den Code des neuen Bootloaders) Zwischenspeicher. Ansonsten allerdings schon, dann braucht er Zwischenspeicher im Umfang des Bootloadercodes abzüglich einer Flash-Page. Das muss aber nicht unbedingt RAM sein, man kann auch EEPROM oder freie Bereiche des Flash im Applikationsbereich dafür verwenden. Allerdings muss der Bootloader, um sich selber "unfallfrei" überschreiben zu können, auch speziell für diesen Zweck designed sein. Das ist kinderleicht umzusetzen, jedenfalls in Assembler, wo man die volle Kontrolle über den Code hat...
Hallo, Arduino IDE genommen, mit Fischl-USB-Isp Programmer den Bootlader(für Nano-Board) in Mega328 gebrannt. Dann nur einmal ist der Bootloader nutzbar, dann ist er weg ?????? Dann habe ich mir doch ein UNO Board gekauft, den ISP-Programmer Sketch eingeladen, per ISP auf einem Breadboard in einen Mega328 den Bootlaoder gebrannt ... und nun alles paletti, hä wie das ??? Bisher keine Antwort gefunden.
c-hater schrieb: > Allerdings muss der Bootloader, um sich selber "unfallfrei" > überschreiben zu können, auch speziell für diesen Zweck designed sein. Das heißt, er muss mindestens zwei Eraseblöcke belegen und sicherstellen, dass er aus dem gerade nicht gelöschten Eraseblock ausgeführt wird. Widerspricht deinem "wenn er nur einen Eraseblock groß ist" ein bisschen...
S. R. schrieb: > Das heißt, er muss mindestens zwei Eraseblöcke belegen und > sicherstellen, dass er aus dem gerade nicht gelöschten Eraseblock > ausgeführt wird. Natürlich benötigt er einige wenige Instruktionen an zwei Stellen im Flash, die nicht in der gleichen Erasepage liegen dürfen. Das macht halt genau das "spezielle Design" aus. > Widerspricht deinem "wenn er nur einen Eraseblock groß ist" ein > bisschen... Nein. Wenn eine Page z.B. 128 Bytes groß ist, dann kann ich die acht Bytes Instruktionen, die in zwei unterschiedlichen Pages liegen müssen, logischerweise bereits bereitstellen, wenn mein Bootloader 16 Bytes groß ist. Das ist sogar deutlich weniger als eine Page... Und ich brauche keinen Pufferspeicher dafür und kann trotzdem alles an Flashinhalt erhalten, was in diesen beiden Pages außer diesen 16 Byte Bootloadercode existiert. Denn man kann zwar nur komplette Pages löschen, aber niemand hält einen davon ab, hinterher gleich wieder (größtenteils) den ursprünglichen Inhalt da rein zu schreiben. Und der interne Flash-Buffer macht es sogar möglich, dies ohne weiteren Bufferspeicher zu realisieren. Natürlich kann man mit 16 Bytes noch keinen vollständigen Bootloader bauen, aber das Beispiel dient ja auch nur dazu, dir den Unterschied zwischen Größe und Alignment zu veranschaulichen. Die sind eben nicht zwingend miteinander verknüpft. Nämlich genau dann nicht, wenn man das Alignment einfach nur für die Teile des Codes beachtet, für die es tatsächlich eine Rolle spielt. Im Falle eines Bootloaders sind das halt die Vektortabelle im Bootloaderbereich, die absolut fix (durch Fuses bestimmt ist) und diese zwei mal acht Bytes für den Kern des Bootloadercodes, die halt auf eine beliebige Pagegrenze -8 aligned sein müssen. Der ganze Rest kann liegen, wo er will.
Zusammengefasst: Der Bootloader muss zwei Pages überspannen, aber nicht unbedingt beide voll ausfüllen. Das ist klar. :-)
Thread beobachten
Seitenaufteilung abschalten
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.