Hat der ATXMega32E5 einen Bootloaderbereich? So wie ich das verstanden habe ja, aber meine Software (Bootloader) findet die SPM-Bits nicht und ich kann deswegen keine hex erzeugen. Hat der eine Bootloader-Section, wenn ja was muss ich dabei beachten oder sind die E-Serie wieder wie die kleinen ATMegas (bspw ATMega48) bei denen man manuell eine Section erstellen muss? Problem ist halt, das die Funktionen boot_write_flash etc... nicht funktionieren, kann der Chip sich selbst beschreiben?
Marius D. schrieb: > Hat der ATXMega32E5 einen Bootloaderbereich? Ja, Datenblatt, Tabelle 2.1 > aber meine Software (Bootloader) findet die SPM-Bits nicht und > ich kann deswegen keine hex erzeugen. SPM ist ein Befehl. Welche Software meinst du? > Hat der eine Bootloader-Section, wenn ja was muss ich dabei beachten > oder sind die E-Serie wieder wie die kleinen ATMegas (bspw ATMega48) bei > denen man manuell eine Section erstellen muss? Du musst deinem Assembler/Compiler schon sagen, was er wohin packen soll. > Problem ist halt, das die Funktionen boot_write_flash etc... nicht > funktionieren, Was für einen Compiler verwendest du? > kann der Chip sich selbst beschreiben? Ja, sonst wäre ein Bootlader sinnlos.
Ich nutze einfach AtmelStudio 6 und 7. Ich habe einen Bootloader für die Xmega/Mega geschreiben, der läuft (bereits auf div. Megas/Tinys und auf Xmega256A3, XMega32A4 und Xmega64A1). In der boot.h finden sich folgende Probleme:
1 | #if defined (SPMCSR)
|
2 | # define __SPM_REG SPMCSR
|
3 | #else
|
4 | # if defined (SPMCR)
|
5 | # define __SPM_REG SPMCR
|
6 | # else
|
7 | # error AVR processor does not provide bootloader support!
|
8 | # endif
|
9 | #endif
|
10 | |
11 | #if defined(SPMEN)
|
12 | # define __SPM_ENABLE SPMEN
|
13 | #elif defined(SELFPRGEN)
|
14 | # define __SPM_ENABLE SELFPRGEN
|
15 | #else
|
16 | # error Cannot find SPM Enable bit definition!
|
17 | #endif
|
und dadruch sind folgende Funktionen unbekannt:
1 | boot_spm_busy_wait(); |
2 | boot_page_erase((unsigned long) i); |
3 | boot_spm_busy_wait(); |
4 | boot_rww_enable(); // reenable rww section again |
Nur ich weiß nicht wirklich warum das nicht geht.
Der E5 nutzt den NVM-Controller für das Beschreiben der internen Speicher. Ein SPMCSR/SPMCR-Register hat er gar nicht.
:
Bearbeitet durch User
Achso, das erklärt das Problem. Wie funktioniert das denn? Wie, bzw. welche funktionen muss ich nutzen als alternative zu den
1 | boot_spm_busy_wait(); |
2 | boot_page_erase((unsigned long) i); |
3 | boot_spm_busy_wait(); |
4 | boot_rww_enable(); // reenable rww section again |
Lade Dir das Manual zum XMEGA_E ´runter - da steht alles drin. Ich frage mich, wie Du das für die anderen XMEGAs hinbekommen haben willst, die ebenfalls den NVM-Controller mit den dazugehörigen Kommandos nutzen.... BTW: Im Gegensatz zu allen anderen XMEGAs ist der E5 angehalten, wenn das Schreiben in´s Flash gerade stattfindet, das heißt, er kann keine Daten für 3.5ms annehmen. Ohne Handshake wird ein Update also schwierig bzw. sehr langsam.
Bei den ATMegas war das ganz einfach mit avr/boot.h. Bei den XMega gab es irgendwo im netz eine boot.h die ich dann bei xmega defined einbinde (anstelle avr/boot.h). Wie bereits gesagt, ich flashe die Daten sowieso via WLAN/Bluetooth oder USB (auf jeden Fall über UART), auf dem PC läuft ein VB Programm was nen Handshake eingebunden hat. Wenn der E5 auch den NVM Controller nutzt, frage ich mich, warum das mit der boot.h nicht geht?!
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.