mikrocontroller.net

Forum: Compiler & IDEs AVR Studio: Section reservieren


Autor: Toni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich suche eine Möglichkeit, dem AVR Studio 4.18 einen Teil des Flashs 
"abzuzwicken", d.h. dieser Bereich wird beim Flashen nicht mehr mit 
überschrieben. Hintergrund: ich will diesen Bereich zur Laufzeit mit 
Daten füllen und diese nicht nach jedem SW-Update neu schreiben 
müssen...

... außerdem sollte ein Linkererror kommen, falls mein Programmcode 
irgendwann doch nicht mehr in den verbleibenden Flashbereich passen 
sollte.

In Beitrag "Memory Sections im AVR Studio" und anderswo ist 
zwar beschrieben wie eine Section eingerichtet wird. Dazu muß ich aber 
einen Code- oder Datenbereich im Sourcecode definieren und diesen dann 
in die zuvor erstellte Section verlinken. Die Größe einer Section ist 
auch nicht einstellbar, lediglich ihre Startadresse.

Wenn ich jetzt aber im Sourcecode (C) einen Datenbereich definiere, der 
meinem freizuhaltenden Bereich entspricht, dann überschreibt Studio bei 
jedem Flash-Befehl meine Userdaten mit ebendiesen Dummy-Daten...

Bitte um Hilfe!
Toni

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hintergrund: ich will diesen Bereich zur Laufzeit mit
>Daten füllen und diese nicht nach jedem SW-Update neu schreiben
>müssen...

Das geht nur, wenn du einen Bootloader benutzt.

Autor: Toni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, das geht (zumindest beim XMEGA) mittels AVR1316 auch "händisch":
            uint16_t address, value;

            address = ADR_MYADDRESS;    // needed because constant can't be used as function argument
            value = (( (uint16_t) myValueHigh) << 8) | myValueLow;
            SP_LoadFlashWord(address, value);    // write in page buffer
            SP_WaitForSPM();

            SP_EraseWriteApplicationPage(ADR_PATTERN_SECTION + (number - 1) * FLASH_PAGE_SIZE);
            SP_WaitForSPM();

Läuft auch schon super, ich will halt nicht ständig nach einem neuen 
SW-Flash alle Daten neu über RS232 nachladen...

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was du beim Compilieren/Linken an Sections definierst (oder reservierst, 
oder was auch immer), interessiert den Programmer im AVR-Studio nicht 
die Bohne. Der löscht beim Programmieren als erstes mal den ganzen 
Flash. Es würde mich wundern, wenn das beim XMega anders wäre.

Autor: Toni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau das ist mein Problem: wie ich den Studio-Programmer davon abhalte, 
das ganze Flash erst mal zu löschen sondern z.B. nur den tatsächlich vom 
Programmcode benötigten Teil...

Ich hab auch keine Stelle gefunden, wo ich die Flashgröße selbst 
definieren könnte. Sobald ich den XMEGA128A1 auswähle, übernimmt Studio 
automatisch alle dessen Speichergrößen (macht ja auch Sinn). Einen 
XMEGA64A1 kann ich übrigens auch auswählen und fehlerfrei übersetzen, 
die 108% Data Belegung stören da offenbar genausowenig wie eine selbst 
definierte Bootsektor-Adresse von 0x20000...

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Toni schrieb:
> Genau das ist mein Problem: wie ich den Studio-Programmer davon abhalte,
> das ganze Flash erst mal zu löschen sondern z.B. nur den tatsächlich vom
> Programmcode benötigten Teil...

Wie soll der Programmer auch etwas machen, was der Chip gar nicht kann? 
Man kann über die ISP-Schnittstelle nicht nur Teile des Flash löschen. 
Jedenfalls ist das bei den "normalen" AVRs so. Du musst halt mal ins 
Datenblatt schauen, ob das bei den XMegas anders ist.

Autor: Toni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der XMEGA hat keine ISP, sondern eine PDI-Schnittstelle. Zitat aus dem 
DB:

"The PDI supports high-speed programming of all Non-Volatile Memory 
(NVM) spaces; Flash,
EEPOM, Fuses, Lockbits and the User Signature Row. This is done by 
accessing the NVM Controller,
and executing NVM Controller commands as described in Memory 
Programming."

und weiter dort:

"The NVM commands that can be used for accessing the NVM memories from 
external programming
are listed in Table 30-5. This is a super-set of the commands available 
for selfprogramming."

Dass der NVM controller einzelne Flashpages löschen und schreiben kann, 
hat er schon bewiesen (siehe Code oben). Table 30-5 enthält auch die 
Zeilen:

"Flash
0x2B Erase Flash Page PDI Write N Y
0x02E Flash Page Write PDI Write N Y
0x2F Erase & Write Flash Page PDI Write N Y
0x78 Flash CRC CMDEX Y Y"

Ich sehe keinen Grund, warum man über PDI keine einzelnen Flashpages 
löschen/schreiben können sollte.

Autor: Tomas Kuckenburg (Firma: tktronic) (tktronic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmmm...

warum nicht den gewünschten flash-inhalt VOR dem Neuprogrammieren
1. in eine Datei auslesen -> alt.hex
2. chip löschen
3. neu app programmieren
4. alt.hex programmieren

sollte relativ fix gehen und du hast deinen flash-datenbereich wieder 
zur verfügung.

Autor: Toni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab ich jetzt auch probiert:
1. Hex mit Applikationsdaten auslesen
2. ausgelesene Datei beschneiden (nur Applikationsdaten bleiben übrig)
3. neue SW programmieren
4. beschnittene applikationsdaten.hex drüber programmieren
5. Ergebnis in out.hex auslesen

Im Ergebnis stehen zwar brav meine Applikationsdaten, die SW ist aber 
mit FF überschrieben worden, obwohl das beschnittene Hex diese Adressen 
gar nicht enthielt :-(

Ich glaub ich lass es einfach dabei.
Vielen Dank für eure Anregungen!
Toni

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Toni schrieb:
> Ich glaub ich lass es einfach dabei.

Gibst du immer so schnell auf?

Mein Vorschlag wäre

1. Hex mit Applikationsdaten auslesen
2. ausgelesene Datei beschneiden (nur Applikationsdaten bleiben übrig)
3. Programm.hex und Applikationsdaten.hex in eine Datei kombinieren 
(z.B. mit hextools)
4. Kombinierte Datei flashen

Oliver

Autor: Toni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Oliver,

danke für die Idee, das sollte auch funktionieren. Allerdings wollte ich 
die Arbeitsschritte beim Neuflashen vereinfachen. und mir das neuerliche 
herunterladen über Rs232 sparen. Wenn ich jetzt schon 2x flashen muss 
(oder 2 HEX files zusammenmergen), dann ist es doch einfacher, jedesmal 
die Applikationsdaten neu über RS232 runterzuladen. Trotzdem vielen Dank 
für die Anregung.
Toni

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.