Hallo, ich versuche gerade den Bootloader aus der Application Note AVR1605 auf einem Atxmega128A1 zum Laufen zu bekommen. Statt auf einen Pin zu reagieren, schreibe ich in der Applikation eine EEPROM Zelle, die im Bootloader abgefragt wird und dann wieder zurückgesetzt wird. Im Bootloader Projekt setze ich .Boot=0x10800 und .text=0x10000. In der define.h ist die page Größe auf 512 gesetzt. Die compilierten hex Dateien (Bootloader und Applikation) füge ich testweise in einer hex Datei zusammen (erst Applikation, letzte Zeile der Datei löschen, Bootloader dahinter anhängen) und lade das Ganze per JTAG in den µC. Das funktioniert auch alles bereits. Die Applikation startet, ich kann die EEPROM Zelle schreiben und nach einem Reset (soft/hard egal) wird der Bootloader gestartet und reagiert auf Terminaleingaben. Nach einem erneuten Reset startet wieder die Applikation, da die EEPROM Zelle zurückgesetzt wurde durch den Bootloader. Über AVRDUDE lässt sich das Flash auslesen und löschen, die Signatur stimmt auch, aber beim Schreiben des Flash kommt immer ein mismatch Fehler bei Adresse 0x0000. Im Flash steht danach nur noch 0xFF. Hier noch der Aufruf von AVRDUDE aus einer .bat Datei: avrdude -px128a1 -PCOM4 -b9600 -cavr911 -e -U flash:w:App.hex pause Wäre froh, wenn mir jemand auf die Sprünge helfen könnte. Viele Grüße Sebastian
Hallo Sebastian, ich habe das gleiche Problem bei einem Atxmega64. Bist du schon weiter gekommen bzw. hast du eine Lösung? Ich denke daß hier das Befüllen der Flashbuffer nicht funktioniert. Diese werden laut Datenblatt auf 0xFF initialisiert. Löschen des Flashes funktioniert bei mir auch. Nur kriege ich kein einziges Bit ins Flash. Wenn du da ev. nen Tip hast wäre super. Danke und Gruß, Schorschi.
Hallo Schorschi, nein, ich bin leider noch nicht weitergekommen. Habe hier noch was gefunden: http://savannah.nongnu.org/bugs/?28744 Allerdings habe ich es mit der dort genannten Revision (1077) noch nicht ausprobieren können. Müsste das Projekt erst mal kompiliert kriegen. Falls du schon weiter bist, würde ich mich über eine Rückmeldung freuen. Viele Grüße Sebastian
Hi, komm ich da irgendwie an die Sourcen ran? Ich bin dabei einen TWI Bootloader zu erstellen. Ich bräuchte hier den Code um diesen mit meinem verlgeichen zu können. Der Assemblertreiber von Atmel funktioniert bei mir wie oben beschrieben nur begrenzt. Löschen geht aber Schreiben nicht. Gruß, Georg.
Hi Georg, du kannst die Revision z.B. mit Tortoise herunterladen. Ich weiß nicht ob es an dem Atmel Bootloader liegt oder an AVRDUDE. Kannst du da was ausschließen? Viele Grüße Sebastian
Hi, bei mir liegt es am Bootloader. Ich hab grad nichts mehr dazwischen. Hab den Code soweit verkleinert damit ich besser testen kann. Wäre es ev. möglich daß du den Code hier hochlädst. Hab kein SVN auf meinem Rechner hier. Gruß, Georg.
Hi Georg, habe es mal als .zip angehängt. Hoffe du kannst mit den Dateien was anfangen. Wenn der Fehler allerdings im Atmel Bootloader selbst ist, kann man AVRDUDE selbst ja ausschließen. Viele Grüße Sebastian
Es gibt aber eine neue Version von AVRDUDE, glaub 6.0; in Archiv ist 5.11 drin.
Hi Martin, ja, ich habe nur die Revision 1077 heruntergeladen, weil hier der Bug behoben sein soll, den es mit dem Xmega Bootloader gibt. Evtl. ist es ja nicht mal ein Problem von AVRDUDE... Gruß Sebastian
Sebastian schrieb: > Statt auf einen Pin zu > reagieren, schreibe ich in der Applikation eine EEPROM Zelle, die im > Bootloader abgefragt wird und dann wieder zurückgesetzt wird. Das geht mit RAM oder GPIOR auch, wenn diese im Bootloader nicht explizit gelöscht werden. Das wäre dann auch verschleißfrei. Da der Bootloader von der Applikation aus über Reset gestartet wird und nicht über Power_On, bleiben die Daten im RAM erhalten. Bei den GPIORs hat man den Vorteil, dass sie bei Power_On mit 0 initialisiert werden und so der Bootloader nach dem Einschalten erst einmal die Applikation startet, wenn sie vorhanden ist. Wenn die Applikation einen Wert !=0 in das GPIOR schreibt, kann der Bootloader entsprechend reagieren.
Hallo Leute, der Code von AVR-Dude hilft mir grad nicht weiter. Bei mir ist es definitiv so dass die Flash-Buffer nicht befüllt werden. Warum auch immer. Deswegen ist auch das Flash nach dem Flashen gelöscht. Denn die Buffer werdne auch mit 0xFF vorinitialisiert bzw. nicht benutzte Bytes damit aufgefüllt. Im Moment ist mir nicht ganz klar warum dies so ist. Entweder der Bootloader von Atmel hat noch nen dicken Bug oder ich hab was vergessen oder mach etwas falsch. Gruß, Georg.
Georg X. schrieb: > Bei mir ist es definitiv so dass die Flash-Buffer nicht befüllt werden. > Warum auch immer. Deswegen ist auch das Flash nach dem Flashen gelöscht. Sind denn alle Teile des Controllers auf das Bescheiben des Flashs entsprechend initialisiert, insbesondere der NVM-Controller? Der A1 hat einige Macken, was den NVM betrifft. Dafür werden im Datenblatt workarounds beschrieben.
Hallo, Ich verwende den ATXMega64A3U. Welche Teile genau sind den gemeint? Der Code ist im Bootloaderbereich des Flashes. Das Löschen des Flashes funktioniert soweit. Beim Beschreiben der FlashPageBuffer gehe ich vor wie im Datenblatt beschrieben: 33.11.2.3 Load Flash Page Buffer The load flash page buffer command is used to load one word of data into the flash page buffer. 1. Load the NVM CMD register with the load flash page buffer command. 2. Load the Z-pointer with the word address to write. 3. Load the data word to be written into the R1:R0 registers. 4. Execute the SPM instruction. The SPM instruction is not protected when performing a flash page buffer load. Repeat step 2-4 until the complete flash page buffer is loaded. Unloaded locations will have the value 0xFFFF. Workarounds sind bei mir im Datenblatt nicht aufgelistet. Für alle weiteren Tips bin ich dankbar. Gruß, Schorschi.
Hallo, erstens muß ich sagen daß der Bootloader unvollständig ist. Ich hab da 2 unterschiedliche Appnotes und bei beiden fehlt einfach einiges im Protokoll. Ich hab dieses einfach an meine Bedürfnisse angepasst. Zusätzlich hab ich die Adresse im flash falsch angegeben. Ich hab diese Wordweise so wie im Datenblatt im Linkerfile eingetragen. Müßen aber Byteweise vorgegeben werden. Jetzt funktionierts. Dauert zwar ne halbe Ewigkeit aber an dieser stelle spielt Zeit keine so große Rolle. Gruß, Georg.
Hallo Georg, woran hast du dich denn dann orientiert, wenn die AppNotes schon fehlerhaft sind? Traurig, dass Atmel dann sowas veröffentlicht. Irgendwie muss ich das mal zum Laufen kriegen... Gruß Sebastian
Hallo, habe es jetzt so weit, dass ich per Bootloader Fuse zwischen Applikation und Bootloader wechseln kann. Der Bootloader selbst lädt auch den Code zum Controller, Verifikation funktioniert. Lese ich dann den Speicher per Atmel Studio aus, fällt auf, dass jeweils ein beschriener Datenblock auf einen unbeschriebenen folgt. Wäre froh, wenn da jemand einen Rat weiß. Gruß Sebastian
Thread beobachten
Seitenaufteilung abschaltenBitte 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.