ATXmega32E5 kein Bootloader möglich? SPM Flag exisitert nicht?!

[MOBA 2. (Gast)]

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?

[Georg G. (df2au)]

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.

[MOBA 2. (Gast)]

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:

#if defined (SPMCSR)
#  define __SPM_REG    SPMCSR
#else
#  if defined (SPMCR)
#    define __SPM_REG    SPMCR
#  else
#    error AVR processor does not provide bootloader support!
#  endif
#endif

#if defined(SPMEN)
#  define __SPM_ENABLE  SPMEN
#elif defined(SELFPRGEN)
#  define __SPM_ENABLE  SELFPRGEN
#else
#  error Cannot find SPM Enable bit definition!
#endif

und dadruch sind folgende Funktionen unbekannt:

boot_spm_busy_wait();
                boot_page_erase((unsigned long) i);
                boot_spm_busy_wait();
                boot_rww_enable();  // reenable rww section again

Nur ich weiß nicht wirklich warum das nicht geht.

[Knut B. (Firma: TravelRec.) (travelrec)]

Der E5 nutzt den NVM-Controller für das Beschreiben der internen 
Speicher. Ein SPMCSR/SPMCR-Register hat er gar nicht.

[MOBA 2. (Gast)]

Achso, das erklärt das Problem.
Wie funktioniert das denn?
Wie, bzw. welche funktionen muss ich nutzen als alternative zu den

boot_spm_busy_wait();
                boot_page_erase((unsigned long) i);
                boot_spm_busy_wait();
                boot_rww_enable();  // reenable rww section again

[Knut B. (Firma: TravelRec.) (travelrec)]

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.

[MOBA 2. (Gast)]

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?!