AVR Bootloader in C - Artikel

Super Artikel! Danke!

So ich habe jetzt den letzten Schliff am Artikel gemacht, jetzt ist er 
erstmal fertig. Ich hoffe noch auf ein bischen Feedback...

abo

@Turmel:

es sollte nicht so stocksteif rüberkommen. Ich fands lustig so.

Danke :)
Ich hoffe ich habe etwas Licht ins Dunkel der Bootloaderei gebracht...

Turmel schrieb:
> Mario Grafe schrieb:
>> @Turmel:
>>
>> es sollte nicht so stocksteif rüberkommen. Ich fands lustig so.
>
> Dann frag halt nicht nach Kritik, wenn Du für Dich selbst schreibst.

Ich schreibe nicht (nur) für mich. Ich hoffe das auch einige andere 
etwas mit dem Artikel anfangen können. Die Kritik zum Schreibstil nehme 
ich gerne an, der nächste Artikel wird förmlicher. Aber den 
Bootloader-Artikel schreibe ich jetzt nicht nochmal komplett um 
deswegen. Das ist mir zuviel Aufwand. Wer damit nicht leben kann der 
soll ihn halt nicht lesen.

Es wäre gut wenn auch inhaltliche Kritik käme oder mal jemand den Code 
ausprobiert...

Hast du pos./neg. Erfahrungen/Empfehlungen zur Verwendung eines 
seriellen Bootloaders, wenn mit dem internen RC-Oszillator (statt 
genauerem externen Taktgeber) gearbeitet wird?

Vielen Dank für die Blumen.

Stefan B. schrieb:
> Hast du pos./neg. Erfahrungen/Empfehlungen zur Verwendung eines
> seriellen Bootloaders, wenn mit dem internen RC-Oszillator (statt
> genauerem externen Taktgeber) gearbeitet wird?

bei 9600 Baud mit ca. 0.2% Fehler geht es mit dem internen Takt von 8Mhz 
wunderbar, mit 19200 Baud auch. Die Baudratentabelle im Datenblatt hilft 
da weiter. Um ein STK500 zu simulieren, muss 115200 Baud unterstützt 
werden. Dafür ist ein externer Quarz unverzichtbar.

Mario

Wäre schön wenn mal jemand den Bootloader ausprobiert :)

Turmel schrieb:
> Aber das mir jemand unterstellt ich würde seinen lockeren Stil meinen,
       ^^^                       ^
       dass                      ,

> wenn ich von seinem Deutsch, also Grammatik und Diktion rede macht mir
                                                              ^
                                                              ,

> nicht gerade Mut mit ihm eine Diskussion über eines der beiden Themen
                  ^
                  ,

> "Stil" und "Grammatik" anzufangen.

4 Fehler in einem Satz. Glashaus, Steine.

Mario Grafe schrieb:
> Es wäre schön, wenn die Gurus unter euch das mal drübergucken könnten
> und Feedback über grobe Fehler oder Anmerkungen geben könnten.

Zum Layout

Hat Potential für Verbesserungen :-)

Beispiel:

1

                        }

2

                        else if(boot_state != BOOT_STATE_PARSER)                /* Programmzustand: UART Kommunikation */

3

                        {

4

                    switch((unsigned char)c)

5

                    {

6

                         ...

7

                    }

8

                        }

9

        }

10

    }

11

    while(boot_state!=BOOT_STATE_EXIT);

#1
Verwende gescheite Einrückungen für die Quelle! Hier sieht man den 
Grund, warum man keine TABs zm Einrücken nehmen sollte: Es sieht 
überall anders aus. Ergo: Einrücktiefe zB 4, und zwar mit Leerzeichen 
.

#2
Ganz offenbar stammt die Quelle von mehreren Autoren. Dennoch sollte 
ein Stil durchgehalten werden.

#3
Viele Quell-Zeilen sind zu lange. Da diese nicht umgebrochen werden, 
führt das dazu, daß die komplette HTML-Seite diese Breite bekommt und 
breitenmässig nicht mehr auf einen Bildschirm passt (Display 1024 pix). 
Zum Lesen muss beständig links-recht gescrollt werden. So macht das 
Lesen keinen Spaß!

Zum C-Code

#4
Warum wird teilweise uint8_t verwendet, teilweise unsigned char? dito 
16-Bit Typen?

#5

1

do

2

{

3

    c = uart_getc();

4

5

    if (c & UART_NO_DATA)

6

        continue;

7

8

    // 150 Zeilen Code

ist besser verständlich als

1

do

2

{

3

    c = uart_getc();

4

    if( !(c & UART_NO_DATA) )

5

    {

6

        // 150 Zeilen Code

7

    }

8

}

Zumal da bis zu 9(!) Einrückebenen folgen.

#6
Kommentare in der gleichen Zeile sind Geschmackssache (ich persönlich 
mag's nicht), aber da die Zeilen teilweise erst bei Spalte > 70 
beginnen, sollte das auf jeden Fall überdacht werden.

#7
Wozu wird an Adresse 0x0000 gesprungen? Sieht nach Hack aus...

#8
Vergleicht man die beiden Implementierungen

1

static uint16_t hex2num(unsigned char *ascii, uint8_t num)

2

{

3

  uint8_t  i;

4

  uint16_t var=0,

5

           erg=0,

6

           mult[4] = {1, 16, 256, 4096};

7

8

  for(i=0; i<num; i++)

9

  {

10

    if(ascii[i]<65) var = ascii[i] - 48;  /* 0..9 */

11

    if(ascii[i]>64) var = ascii[i] - 55;   /* A..F */

12

    if(ascii[i]>96) var = ascii[i] - 87;  /* a..f */

13

    erg += (uint16_t)(var * mult[num-i-1]);

14

  }

15

  return erg;  

16

}

17

18

static uint16_t hex2num_2 (const uint8_t * ascii, uint8_t num)

19

{

20

    uint8_t  i;

21

    uint16_t val = 0;

22

23

    for (i=0; i<num; i++)

24

    {

25

        uint8_t c = ascii[i];

26

27

        /* Hex-Ziffer auf ihren Wert abbilden */

28

        if (c >= '0' && c <= '9')            c -= '0';  

29

        else if (c >= 'A' && c <= 'F')       c -= 'A' - 10;

30

        else if (c >= 'a' && c <= 'f')       c -= 'a' - 10;

31

32

        val = 16 * val + c;

33

    }

34

35

    return val;  

36

}

So fällt auf:
# die zweite Implementierung ist leichter verständlich, zumindest für 
mich. Es gibt da keine magischen Zahlen und keine seltsame 
Multiplikation über ein Konstanten-Array.

# Die zweite Version brauch ca. 80 Bytes, die erste rund 190 Bytes an 
Code. An RAM braucht die zweite 2 Bytes für die Return-Adresse. Die 
erste Version legt bei jedem(!) Aufruf mult als Array auf dem Stack an 
und muss erst die Werte dort hinkopieren. Sie braucht 18 Bytes an Stack 
(avr-gcc 4.3.3, -Os).

Ich weiß jetzt nicht wie großzügig man in einem Bootloader mit den 
Resourcen haushalten kann...

#9
Für einige Aufgaben bieten sich Funktionen an, um den Spaghetti-Code 
etwas zu entschärfen. ZB das Parser-Zeug. gcc wird das inlinen, und wenn 
nicht, hat er gute Gründe dafür (inlining macht den Code auch bei einem 
Aufruf nicht unbedingt kleiner). Variablen wie "flag" braucht's dann 
nicht mehr, "c" lebt besser in dem Block, wo es verwendet wird...

Ok, hier mach ich mal Schluss, sonst find ich kein Ende... :-)

Und bitte nicht falsch verstehen. Ich schreib das nicht alles um 
rumzumäkeln (das wär mit die Schreibarbeit nicht wert), sondern weil ich 
Anregungen geben möchte. Text wird eben nicht nur über seine Buchstaben 
wahrgenommen, sondern zum Großteil auch über sein Layout/seine 
Typographie.

@Johann L.:
Danke, solche Anmerkungen und Anregungen habe ich gemeint. Wenn man 
immer nur in seiner eigenen Suppe schwimmt, merkt man sowas nicht. 
Sobald ich Zeit habe, werde ich mich über deine Vorschläge hermachen und 
sie einarbeiten.
Die hex2num-Funktion von dir sieht tatsächlich viel besser aus, die 
würde ich so übernehmen.Die Quellen stammen übrigens tatsächlich alle 
von mir persönlich. Die falsche Einrückungen durch Tabs kommen durch das 
Copy&Paste in den Wiki-Editor zustande, das habe ich übersehen. Da ich 
einen ziemlich breiten Monitor habe sind mir einige "Breitenfehler" 
nicht aufgefallen.

@ Johann L.:
ich habe jetzt schon einige Verbesserung des Layouts eingebaut (Tabs 
entfernt, Kommentare in eigene Zeile). Es sieht tatsächlich besser aus 
:)
Mein Funktion hex2num ist nicht besonders schön. Dein Vorschlag gefällt 
mir besser, ich habe ihn so übernommen. Danke nochmal. Jetzt werde ich 
mich noch mit dem "Hack" start() beschäftigen... er funktioniert zwar 
aber ein vom WDT ausgelöster Reset ist besser denke ich.

@ Olli:
habe ich geändert, danke für den Hinweis.

Johann L. schrieb:
> #7
> Wozu wird an Adresse 0x0000 gesprungen? Sieht nach Hack aus...

Hallo Johann,
ich habe jetzt mal ausprobiert, den Bootloader mittels Watchdog reseten 
zu lassen, aber dabei entsteht ein Henne-Ei-Problem. Der AVR springt ja 
nach dem Reset immer wieder zuerst an Adresse 0x1800, dann wird nach 3 
sec. wieder geresetet und er landet wieder bei 0x1800. Der Bootloader 
springt also nie zur Anwendung weiter. Der "Hack" springt hart zur 
Adresse 0x0000, eigentlich doch nicht so schlecht, was meinst du? Gibt 
es noch eine andere Lösung die Anwendung loslaufen zu lassen?

Gruß
Mario

@ Johann L.:
Kennst du eine elegante Möglichkeit wie man die Fuses vom Bootloader aus 
setzten kann?

Mario Grafe schrieb:
> Der "Hack" springt hart zur
> Adresse 0x0000, eigentlich doch nicht so schlecht, was meinst du? Gibt
> es noch eine andere Lösung die Anwendung loslaufen zu lassen?

Nein.
Der Resetvector ist ja auf den Bootloader verbogen und das läßt sich nur 
per Fusebit ändern.
Du mußt nach 0x0000 springen, das ist die saubere Lösung (kein Hack).

Du kannst auch nach oben aus dem Bootloader rauslaufen (mit NOPs bis zum 
Ende auffüllen), aber das würde ich als "dreckigen Hack" bezeichnen.


Peter

Mario Grafe schrieb:
> Kennst du eine elegante Möglichkeit wie man die Fuses vom Bootloader aus
> setzten kann?

Einen ATtiny25 an SPI + Reset anklemmen, und so programmieren, daß er 
per ISP die Fuses ändert.

In der Regel sollte aber die Schaltung bekannt sein, in der der 
Bootloader arbeitet, also sollte man die Fuses gleich richtig setzen 
können.


Peter

Peter Dannegger schrieb:
> Mario Grafe schrieb:
>> Der "Hack" springt hart zur
>> Adresse 0x0000, eigentlich doch nicht so schlecht, was meinst du? Gibt
>> es noch eine andere Lösung die Anwendung loslaufen zu lassen?
>
> Nein.
> Der Resetvector ist ja auf den Bootloader verbogen und das läßt sich nur
> per Fusebit ändern.
> Du mußt nach 0x0000 springen, das ist die saubere Lösung (kein Hack).

Das Problem mit "goto 0" ist, daß das kein Reset ist, sondern eben nur 
ein "goto 0". Das initialisiert nicht die Hardware. Andererseits sind 
viele Anwendungen so geschrieben, daß sie von einer initialisierten 
Hardware ausgehen, zB Timer-Initialisierungen oder 
UART-Initialisierungen etc. die |= verwenden beim Belegen von SFRs wo 
sie eigentlich = meinen. Mit einer vor-initialisierten Hardware kann das 
zu Problemen führen.

Ich sehe da 2 Lösungsansätze

A: Der Bootloader macht seine Initialisierungen rückgängig und schreibt 
die entsprechenden Reset-Werte in die angefassten SFRs.

B: Man macht einen WDT-Reset und fragt nach dem Reset in Bootloader die 
Reset-Ursache ab. War's ein WDT-Reset, folgt ein "goto 0". Nachteil: Die 
Anwendung kann diesen Mechanismus nicht mehr verwenden, um nach einem 
eigenen WDT-Reset neu aufzusetzten (zB wenn nach einem WDT nicht neu 
initialisiert werden darf sondern an einem "Milestone" sicher aufgesetzt 
werden muss)

Peter Dannegger schrieb:
> Einen ATtiny25 an SPI + Reset anklemmen, und so programmieren, daß er
> per ISP die Fuses ändert.
>
> In der Regel sollte aber die Schaltung bekannt sein, in der der
> Bootloader arbeitet, also sollte man die Fuses gleich richtig setzen
> können.

Gibt es keine Möglichkeit, die Fuses des eigenen AVR vom 
Bootloaderbereich aus zu ändern? Hintergrund: Ich habe den Bootloader 
daahingehend erweitert, das er sich wie ein STK500 verhält. Flashen usw. 
klappt auch ganz wunderbar, nur die Fuses kann ich nicht ändern.
Dieser Bastler hier: 
http://hubbard.engr.scu.edu/embedded/avr/bootloader/index.html
macht im Prinzip das gleiche, er muß es auch irgendwie gelöst haben, 
leider gibt er die Quellen nicht raus. Ich dächte ich hätte so etwas 
auch schon irgendwo mal gelesen, ich find es nur nicht mehr. Man muß 
natürlich aufpassen, das man sich nicht aus dem Bootloader aussperrt, 
aber das kann man ja abfangen. Nach dem Start hat man 3 Sekunden Zeit 
sich über das AVRStudio mit dem AVR zu verbinden, dann springt er weiter 
zum Programm, eigentlich ein schicke Sache. Wenn es fertig ist, werde 
ich es mal posten.

Ich bin froh das du mal über meinen Code schaust, du hast ja selbst 
schon einige Bootloader geschrieben und bist sehr aktiv und kompetent im 
Forum unterwegs. Wie findest du den Artikel?

Mario Grafe schrieb:

> Dieser Bastler hier:
> http://hubbard.engr.scu.edu/embedded/avr/bootloader/index.html
> macht im Prinzip das gleiche, er muß es auch irgendwie gelöst haben,
> leider gibt er die Quellen nicht raus.

Ich denke das hast du misverstanden.
Der Bootloader selbst ändert keine Fuse Bits. Die muss man mit einem 
richtigen Programmer umstellen, wenn man den Bootloader in den µC 
brennt.

Karl heinz Buchegger schrieb:
> Mario Grafe schrieb:
>
>> Dieser Bastler hier:
>> http://hubbard.engr.scu.edu/embedded/avr/bootloade...
>> macht im Prinzip das gleiche, er muß es auch irgendwie gelöst haben,
>> leider gibt er die Quellen nicht raus.
>
> Ich denke das hast du misverstanden.
> Der Bootloader selbst ändert keine Fuse Bits. Die muss man mit einem
> richtigen Programmer umstellen, wenn man den Bootloader in den µC
> brennt.

Aha, schade eigentlich. Sonst könnte man wenigstens noch die Taktquelle 
ändern oder so. Kannst du bitte auch mal über den Artikel schauen ob 
grobe Schnitzer drin sind, würde mich freuen. Schön wäre es auch wenn es 
mal jemand ausprobiert :)

delay schrieb:
> Hallo,
> kleiner Tipp von mir, statt in jedem case Zweig Xoff und wieder Xon zu
> schicken kannst du das auch vor und nach dem Switch machen. Danke für
> den Artikel.

Da habe ich auch schon dran gedacht. Müßte man mal probieren. Könnte 
sein das die Kommunikation dann langsamer wird da der AVR ständig den 
Empfang stoppt.

Hallo Mario und vielen Dank erstmal für den guten Artikel!
Auf mich wirkte er tatsächlich sehr demystifizierend und hat mir erst 
einmal ein grundsätzliches Verständnis für die Problematik gegeben.
Die Kommentare zur Rechtschreibung können wir mal getrost überlesen, die 
zu Übersichtlichkeit des Quelltextes nicht ganz. Aber dazu wurden schon 
genug Worte verloren.
Ich habe viel mehr eine konkrete Frage. Und zwar erschließt sich mir 
bisher der Sinn der Verwendung des Intel-HEX-Formates nicht, wenn dieses 
nur bewirkt, dass ich erst wieder einen Parser auf dem µC oder PC 
brauche um es zu interpretieren. Warum lasse ich mir vom Makefile nicht 
gleich mittels avr-objcopy eine Bin-Datei ausspucken und sende diese 
dann via UART an den µC?
Daran schließt sich mir auch gleich noch eine zweite Frage an. Und zwar 
bzgl. der Interpretation des Binärformates: Kann ich das so verstehen, 
dass ich einfach stets 64 Bytes (1 Page) aus der Bin-Datei auslese und 
diese nacheinander in die Speicherbereiche ab 0x0000 hochzählend 
reinschreiben kann? Oder wie muss ich mir den Aufbau des Binärformates 
vorstellen? Hab dazu nix richtig aussagekräftiges gefunden (zumindest 
nichts was mir Klarheit verschafft hat ;-) ).

Danke schon mal für die Antwort(en).

Christoph P. schrieb:
> brauche um es zu interpretieren. Warum lasse ich mir vom Makefile nicht
> gleich mittels avr-objcopy eine Bin-Datei ausspucken und sende diese
> dann via UART an den µC?

Dimit ginge zumindest kein XON/XOFF mehr, weil dann alle Hex-Werte 
00..ff belegt wären. Zudem hat man so ne kleine Konsistenzpfüfung via 
Prüfsumme.

Christoph P. schrieb:
> Ich habe viel mehr eine konkrete Frage. Und zwar erschließt sich mir
> bisher der Sinn der Verwendung des Intel-HEX-Formates nicht, wenn dieses
> nur bewirkt, dass ich erst wieder einen Parser auf dem µC oder PC
> brauche um es zu interpretieren. Warum lasse ich mir vom Makefile nicht
> gleich mittels avr-objcopy eine Bin-Datei ausspucken und sende diese
> dann via UART an den µC?
> Daran schließt sich mir auch gleich noch eine zweite Frage an. Und zwar
> bzgl. der Interpretation des Binärformates: Kann ich das so verstehen,
> dass ich einfach stets 64 Bytes (1 Page) aus der Bin-Datei auslese und
> diese nacheinander in die Speicherbereiche ab 0x0000 hochzählend
> reinschreiben kann? Oder wie muss ich mir den Aufbau des Binärformates
> vorstellen? Hab dazu nix richtig aussagekräftiges gefunden (zumindest
> nichts was mir Klarheit verschafft hat ;-) )

wie schon Johann L. schrieb: Beim Binärformat werden die empfangenen 
Daten als "echte" Binärzahlen interpretiert, d.h. wenn man eine binäre 5 
(0x05) sendet, wird sie auch als 5 gewertet. Leider ist dann die 
Flußsteuerung mit XON/XOFF nicht mehr möglich, da der gesamte Symbolraum 
ausgenutzt wird. Natürlich könnte man auch auf "echte" Flußsteuerung á 
la RTS/CTS umsteigen, aber das werden wohl die wenigsten implementiert 
haben. Zum Aufbau der Binärdatei kann ich nicht viel sagen, daher habe 
ich mich für den HEX-File-Parser entschieden, zumal keine avr-objcopy 
o.ä. nötig ist. Der Artikel sollte so einfach und verständlich wie 
möglich werden, so dass möglichst viele etwas damit anfangen können. Es 
ist auch als Anregung zu verstehen die Sache weiterzuentwicklen oder 
damit zu "spielen". Das schöne ist ja auch das durch die 
Hardwareunabhängikeit durch C der Bootloader für jeden AVR (mit 
Bootloadersupport) ohne Änderungen kompiliert werden kann.
Ich persönlich habe auch erst vor kurzem Angefangen mich speziell mit 
Bootloadern zu beschäftigen. Ich habe letztens noch einen Bootloader 
geschrieben, der sich wie ein STK500 verhält, dann wir das programmieren 
noch einfacher. Er passt auch wunderbar in die 2k, werde ich bei 
Gelegenheit mal posten.

delay schrieb:
> z.B nach dem ":" einfach die ersten 8byte wegschmeißen und dann die
> nächsten 32 Byte lesen, usw. Das das Hexfile mit 0 Anfängt usw nimmt man
> einfach an. (naja den recodtype sollte man vielleicht noch auswerten um
> das ende zu bestimmen)

Naja abspecken wird schwierig. Man kann den Header nicht 
vernachlässigen. Die Daten stehen nicht so in der Hex-Datei wie sie 
Binär im Speicher liegen. Da sind Sprünge drin, die müssen ausgewertet 
werden. Es muß immer die Adresse ausgewertet. Eigentlich müßte der 
Parser noch erweitert werden für RecordTyp 3 bis 5, um Adressoffsets 
zuzulassen, bis jetzt sind nur 64kB addressierbar (RecordTyp 1 geht bis 
0xFFFF).
Vielleicht hat ja jemand Lust das mal zu implementieren.

Mario Grafe schrieb:

> Vielleicht hat ja jemand Lust das mal zu implementieren.

Am besten gleich mit flex/bison :o)

So, ich hab mich nun mal näher mit dem HEX-Format beschäftigt und muss 
mich aufgrund der Verwendung eines ATmega1281 sowieso mit den 
Datensatztypen 02 bis 05 beschäftigen. Dazu folgende Fragen:

1. Warum gibt es zwei verschiedene Modi/Record Types für die 
Adressierung von Speicherplätzen über 64k? Zum einen den Extended 
Segment Address Record (02) bei dem den folgenden Adressen ein Offset 
aufaddiert wird und zum andern der Extended Linear Address Record (04) 
bei dem den folgenden Adressen 4 höherwertige Bits vorrangestellt werden 
und der Adressraum somit noch größer ist? Ist dies Compiler- oder 
Architekturabhängig?

2. Der Record Type 03 (Start Segment Address Record) beinhaltet meines 
Verständnis nach den Startpunkt (Zeiger) der Anwendung falls sie nicht 
bei 0x0000 liegt (falls nicht, bitte korrigieren). Wozu dient dann noch 
der Record Type 05 (Start Linear Address Record)?

Wenns Erfolge bei mir gibt bzgl. höherem Adressraum, kann ich den 
entsprechenden Quelltext gern hier beisteuern. Und für Hinweise bzgl. 
meiner Frage zum schreiben/flashen des BIN-Formats gibt, bin ich 
weiterhin offen dafür ;)

Olli schrieb:
> ich finde den Artikel zum Bootloader echt klasse. Kommt dann demnächst
> noch die Erweiterung auf den STK500-kompatiblen Bootloader?
Danke für die Blumen. Sobald ich Zeit habe, poste ich den 
STK500-kompatiblen Bootloader, er ist zu 90% fertig.

Jörg schrieb:
> Ist es ein Versehen, dass statt dem üblichen CR+LF-Newline ("\r\n") ein
> "\n\r" verwendet wird? Für mich ist es etwas irritierend.
Ja das ist ein Versehen, aber das Ergebnis ist das Gleiche. Könnte man 
der Schönheit wegen noch ändern.

Jörg schrieb:
> Noch eine Kleinigkeit: Die Screenshots vom Terminal stimmen zum Teil
> nicht mit den Ausgaben des Quellcodes überein. Stichwort: Gemischtes
> Englisch - Deutsch.
Richtig, das hat sich noch ein Screenshot einer Vorgängerversion 
eingeschlichen (beim "Hallo Welt"-Bootloader). Muß ich noch berichtigen.

manni schrieb:
> Hallo, geht das auch ohne AVR-Studio , nur mit Winavr und dann rüber?

Selbstverständlich! Letztenendes steckt ja auch nur WinAVR dahinter. Du 
brauchst allerdings ein makefile, in dem du die Verschiebung der Sektion 
.text als Option -Ttext=0xXXXX mitgeben kannst.

So, die alten Screenshots von Putty für den "Hallo Welt"-Bootloader habe 
ich aktualisiert. Die waren nicht mehr konsistent.

So, nachdem ich im AVRFreaks-Forum gelesen habe, dass der Record Type 03 
(start segment address record) bei AVRs keine Bedeutung hat 
(http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=650574 
Beitrag 6) muss im Grunde für AVRs mit >64 KB nur noch der Record Type 
02 (extended segment address record) ausgewertet werden. Alles kein 
Problem, funktioniert bei mir schon ganz gut. Nur stellt sich mir dann 
folgendes Problem: Wie kann ich - außer durch Eingabe eines festen 
Wertes à la

1

void (*start_application)(void) = 0x10000;

 eine Adresse an den Funktionszeiger übergeben?
Ich stelle mir das ungefähr so vor:

1

void (*start_application)(void);

2

uint32_t applicationAddress = 0x00010000;

3

4

start_application = (void *) (uint16_t) applicationAddress;

5

start_application = (void *) &start_application + (uint16_t) (applicationAddress >> 16);

oder alternativ ganz einfach:

1

start_application = (void *) (uint32_t) applicationAddress;

Funktioniert (natürlich) beides nicht. In der Doku der avr-libc steht 
unter 11.14 dazu folgendes:
> pointers are 16 bits (function pointers are word addresses, to allow
> addressing up to 128K program memory space)
Wie kann ich dem Funktionszeiger nun eine Variable mit dem gewünschten 
Adressinhalt übergeben?

Christoph P. schrieb:
> Wie kann ich dem Funktionszeiger nun eine Variable mit dem gewünschten
> Adressinhalt übergeben?

Die Applikation sollte doch an Adresse 0x0000 (0x00000000) starten. 
Damit sollte es doch kein Problem geben, oder?

Ansonsten muß man inline Assembler nehmen, siehe "jmp", also etwa so:

1

asm volatile("jmp 0x8000");

Die Adresse muß meines wissens als Word-Adresse angegeben werden, daher 
0x10000/2=0x8000.

Kannst du deine Änderungen für den Segment Type 02 mal posten?

Mario Grafe schrieb:
> Christoph P. schrieb:
>> Wie kann ich dem Funktionszeiger nun eine Variable mit dem gewünschten
>> Adressinhalt übergeben?
>
> Die Applikation sollte doch an Adresse 0x0000 (0x00000000) starten.
> Damit sollte es doch kein Problem geben, oder?
>
> Ansonsten muß man inline Assembler nehmen, siehe "jmp", also etwa so:asm 
volatile("jmp 0x8000");
> Die Adresse muß meines wissens als Word-Adresse angegeben werden, daher
> 0x10000/2=0x8000.

So lange die neue Anwendung bei der Adresse 0x0000 beginnt ist das kein 
Problem, richtig. Möchte ich aber zwei Anwendungen auf dem µC haben und 
zwischen diesen Anwendungen mittels des Bootloaders wählen können, dann 
muss ich bei (dementsprechend großen) Firmwares irgendwann auch mal in 
den Speicherbereich >64 KB hineinspringen können. Dies würde ich gern so 
"dynamisch" wie möglich machen, in dem die Startadressen der Anwendungen 
aus den HEX-Dateien gelesen, gespeichert und bei Bedarf aufgerufen 
werden.
In der avr-libc bin ich nun noch auf den uint_farptr_t gestoßen: 
http://www.nongnu.org/avr-libc/user-manual/group__avr__inttypes.html#ga72b6692e3f3123903c1a0d9a960c59b1

1

typedef int32_t int_farptr_t

> signed integer type that can hold a pointer > 64 KB
Also an irgendeiner Stelle hab ich gerade einfach noch ein 
Verständnisproblem - Byteaddresse, Wortadresse, Farpointer. Vielleicht 
kann mir da noch jemand auf die Sprünge helfen, denn 0x10000/2 = 0x8000 
=> jmp 0x8000 funktioniert auch nicht.

> Kannst du deine Änderungen für den Segment Type 02 mal posten?
Gern, nur der Record Type 03 ist (wie gesagt) völlig sinnfrei von mir 
implementiert wurden. Hab den Parser nur mal in eine eigene Funktion 
ausgelagert.

1

// boolean-defintion for software-flags

2

typedef enum

3

{

4

  FALSE,

5

  TRUE

6

} bool_t;

7

8

/**

9

 * Parser for the received HEX-file content

10

 */

11

void parse_hex_input(uint16_t receivedHexChar)

12

{

13

  static uint8_t parserState = PARSER_STATE_START,

14

      hexSize = 0,        // length of the Intel-HEX data

15

      hexRecType = 0,        // Intel-HEX record-type

16

      hexChecksumEOL = 0,      // received HEX-file checksum

17

      hexCounter = 0,        // writing position of the HEX-buffer

18

      hexDataCounter = 0;      // counter of received HEX-data of one row

19

20

  static uint16_t hexChecksum = 0,  // Intel-HEX checksum to proof received data

21

      codeSgmntAddr = 0,      // code segment address for record-type == 03

22

      instructionPtr = 0;      // instruction pointer for record-type == 03

23

24

  static bool_t  extSgmntAddrFlag = FALSE,  // flag indicating record-type == 02

25

      csRegisterFlag = FALSE,    // flag indicating code segment address of record-type == 03

26

      ipRegisterFlag = FALSE,    // flag indicating instruction pointer of record-type == 03

27

      flashPageFlag = TRUE,    // flag indicating new flash-page

28

      firstDataLineFlag = TRUE;  // flag indicating that first line of HEX-file is read

29

30

#if (SPM_PAGESIZE > 255)  // AVRs with 128k or more flash-memory

31

  static uint16_t flashCounter = 0;  // writing position of the flash-data buffer

32

  static uint32_t hexAddrOffset = 0,  // address offset of the extended segment address record-type

33

        hexAddress = 0,      // Intel-HEX target address

34

        flashPage = 0;      // to be written flash-page

35

#else            // AVRs with less than 128k flash-memory

36

  static uint8_t flashCounter = 0;  // writing position of the flash-data buffer

37

  static uint16_t hexAddrOffset = 0,  // address offset of the extended segment address record-type

38

        hexAddress = 0,      // Intel-HEX target address

39

        flashPage = 0;      // to be written flash-page

40

#endif

41

42

  hif_putc(XOFF);

43

44

  switch (parserState)

45

  {

46

  // wait for START_OF_LINE sign (':')

47

  case PARSER_STATE_START:

48

    if (receivedHexChar == START_OF_LINE)

49

    {

50

      parserState = PARSER_STATE_SIZE;

51

      hexCounter = 0;

52

      hexChecksum = 0;

53

    }

54

    break;

55

56

  // parse data-size

57

  case PARSER_STATE_SIZE:

58

    hexDataBuffer[hexCounter++] = (uint8_t) receivedHexChar;

59

    if (hexCounter == 2)

60

    {

61

      parserState = PARSER_STATE_ADDRESS;

62

      hexCounter = 0;

63

      hexSize = (uint8_t) hex2num(hexDataBuffer, 2);

64

      hexChecksum += hexSize;

65

    }

66

    break;

67

68

  // parse target address

69

  case PARSER_STATE_ADDRESS:

70

    hexDataBuffer[hexCounter++] = (uint8_t) receivedHexChar;

71

    if (hexCounter == 4)

72

    {

73

      parserState = PARSER_STATE_RECORD_TYPE;

74

      hexCounter = 0;

75

      hexAddress = (uint32_t) hex2num(hexDataBuffer, 4);

76

//      hexChecksum += (uint8_t)((hexAddress & 0xFF00) >> 8);

77

//      hexChecksum += (uint8_t)(hexAddress & 0x00FF);

78

            hexChecksum += (uint8_t) hexAddress;

79

            hexChecksum += (uint8_t) (hexAddress >> 8);

80

      if (hexAddrOffset != 0)

81

        hexAddress += hexAddrOffset;

82

83

      if(flashPageFlag == TRUE)

84

      {

85

        //flashPage = (uint16_t)((hexAddress / SPM_PAGESIZE) * SPM_PAGESIZE);

86

        flashPage = hexAddress - hexAddress % SPM_PAGESIZE;

87

        flashPageFlag = FALSE;

88

      }

89

    }

90

    break;

91

92

  // parse row-type

93

  case PARSER_STATE_RECORD_TYPE:

94

    hexDataBuffer[hexCounter++] = (uint8_t) receivedHexChar;

95

    if(hexCounter == 2)

96

    {

97

      hexCounter = 0;

98

      hexDataCounter = 0;

99

      hexRecType = (uint8_t) hex2num(hexDataBuffer, 2);

100

      hexChecksum += hexRecType;

101

      switch ((uint8_t) hexRecType)

102

      {

103

        case 0:  // data record

104

          parserState = PARSER_STATE_DATA;

105

          if (firstDataLineFlag == TRUE)

106

          {

107

            appStartAddr = hexAddress;

108

            firstDataLineFlag = FALSE;

109

          }

110

          break;

111

        case 1:  // end of file record

112

          parserState = PARSER_STATE_CHECKSUM;

113

          break;

114

        case 2:  // extended segment address record

115

          extSgmntAddrFlag = TRUE;

116

          parserState = PARSER_STATE_DATA;

117

          break;

118

        case 3:  // start segment address record

119

          csRegisterFlag = TRUE;

120

          parserState = PARSER_STATE_DATA;

121

          break;

122

/*        case 4:  // extended linear address record

123

          parserState = PARSER_STATE_DATA;

124

          break;

125

        case 5: // start linear address record

126

          parserState = PARSER_STATE_DATA;

127

          break;

128

        default:

129

          parserState = PARSER_STATE_DATA;

130

          break;*/

131

      }

132

    }

133

    break;

134

135

  // parse flash-data

136

  case PARSER_STATE_DATA:

137

    hexDataBuffer[hexCounter++] = (uint16_t) receivedHexChar;

138

    if(extSgmntAddrFlag == FALSE && csRegisterFlag == FALSE && ipRegisterFlag == FALSE && hexCounter == 2)

139

    {

140

      hif_putc('.');

141

      hexCounter = 0;

142

      flashDataBuffer[flashCounter] = (uint8_t) hex2num(hexDataBuffer, 2);

143

      hexChecksum += flashDataBuffer[flashCounter];

144

      flashCounter++;

145

      hexDataCounter++;

146

      if(hexDataCounter == hexSize)

147

      {

148

        parserState = PARSER_STATE_CHECKSUM;

149

        hexDataCounter = 0;

150

        hexCounter = 0;

151

      }

152

      // buffer full => write page

153

      if(flashCounter == SPM_PAGESIZE)

154

      {

155

        hif_puts("P\n\r");

156

        //program_page((uint16_t) flashPage, flashDataBuffer);

157

        program_page(flashPage, flashDataBuffer);

158

        memset(flashDataBuffer, 0xFF, sizeof(flashDataBuffer));

159

        flashCounter = 0;

160

        flashPageFlag = TRUE;

161

      }

162

    }

163

    else if (extSgmntAddrFlag == TRUE && hexCounter == 4)

164

    {

165

      extSgmntAddrFlag = FALSE;

166

      hexCounter = 0;

167

      hexAddrOffset = (uint32_t) hex2num(hexDataBuffer, 4);

168

//      hexChecksum += (uint8_t)((hexAddrOffset & 0xFF00) >> 8);

169

//      hexChecksum += (uint8_t)(hexAddrOffset & 0x00FF);

170

            hexChecksum += (uint8_t) hexAddrOffset;

171

            hexChecksum += (uint8_t) (hexAddrOffset >> 8);

172

            hexAddrOffset *= 16;

173

      parserState = PARSER_STATE_CHECKSUM;

174

    }

175

    else if (csRegisterFlag == TRUE && hexCounter == 4)

176

    {

177

      hexCounter = 0;

178

      csRegisterFlag = FALSE;

179

      ipRegisterFlag = TRUE;

180

      codeSgmntAddr = (uint16_t) hex2num(hexDataBuffer, 4);

181

            hexChecksum += (uint8_t) codeSgmntAddr;

182

            hexChecksum += (uint8_t) (codeSgmntAddr >> 8);

183

      parserState = PARSER_STATE_DATA;

184

    }

185

    else if (ipRegisterFlag == TRUE && hexCounter == 4)

186

    {

187

      hexCounter = 0;

188

      ipRegisterFlag = FALSE;

189

      instructionPtr = (uint16_t) hex2num(hexDataBuffer, 4);

190

            hexChecksum += (uint8_t) instructionPtr;

191

            hexChecksum += (uint8_t) (instructionPtr >> 8);

192

            parserState = PARSER_STATE_CHECKSUM;

193

    }

194

    break;

195

196

  // parse checksum

197

  case PARSER_STATE_CHECKSUM:

198

    hexDataBuffer[hexCounter++] = (uint16_t) receivedHexChar;

199

    if(hexCounter == 2)

200

    {

201

      hexChecksumEOL = (uint8_t) hex2num(hexDataBuffer, 2);

202

      hexChecksum += hexChecksumEOL;

203

      hexChecksum &= 0x00FF;

204

      // end of file => write remaining data

205

      if (hexRecType == 1)

206

      {

207

        hif_puts("P\n\r");

208

        //program_page((uint16_t) flashPage, flashDataBuffer);

209

        program_page(flashPage, flashDataBuffer);

210

        extSgmntAddrFlag = FALSE;

211

        bootState = BOOT_STATE_EXIT;

212

      }

213

      if (hexChecksum == 0)

214

        parserState = PARSER_STATE_START;

215

      else

216

        parserState = PARSER_STATE_ERROR;

217

    }

218

    break;

219

220

  case PARSER_STATE_ERROR:

221

    hif_puts("Error!\n");

222

    bootState = BOOT_STATE_ECHO;

223

    break;

224

225

  default:

226

    break;

227

  }

228

229

  hif_putc(XON);

230

}

Ok, ich rudere zurück. Wortadressierung mittels

1

appStartAddress /= 2;

 und anschließender Übergabe

1

start_application = (void *) (uint16_t) appStartAddr;

 funktioniert scheinbar doch 8-)

Christoph P. schrieb:
> Ok, ich rudere zurück. Wortadressierung mittelsappStartAddress /= 2; und 
anschließender Übergabestart_application = (void *) (uint16_t) appStartAddr; 
funktioniert scheinbar doch 8-)

Das würde mich aber wundern, dann dürfte ja

1

void (*bootloader)( void ) = 0x1800;

nicht funktionieren...

Ein verzwickeltes Problem...

Nochmal nachgefragt:
Bist du sicher das du mehrere Anwendungen im Flash ablegen willst? Wie 
hantierst du dann mit Interrupts (Stichwort: Sprungtabelle)? Was ist mit 
dem Stack?

Mario Grafe schrieb:
> Christoph P. schrieb:
>> Ok, ich rudere zurück. Wortadressierung mittels appStartAddr /= 2; und
>> anschließender Übergabe start_application = (void *) (uint16_t) appStartAddr;
>> funktioniert scheinbar doch 8-)
>
> Das würde mich aber wundern, dann dürfte ja void (*bootloader)( void ) = 0x1800;
> nicht funktionieren...
>
> Ein verzwickeltes Problem...

Ja, das habe ich auch erst gedacht. Aber kann es sein, dass der Compiler 
bei der zweiten Version automatisch die Halbierung der Flashadresse 
vornimmt, da Funktionszeiger ja stets Wortadressen sind? Nur eine vage 
Vermutung.

Das mit den mehreren Anwendungen hat sicher noch so seine Tücken. 
Speicherkonsistenz, Interrupt-Initialisierung/-Deinitialisierung usw. 
Aber prinzipiell müsste es doch gehen, oder sehe ich das verkehrt? Was 
du mit Stack meinst verstehe ich gerade nicht ganz. Aber beim PC 
funktioniert's doch auch 8-)

Christoph P. schrieb:
> Das mit den mehreren Anwendungen hat sicher noch so seine Tücken.
> Speicherkonsistenz, Interrupt-Initialisierung/-Deinitialisierung usw.
> Aber prinzipiell müsste es doch gehen, oder sehe ich das verkehrt? Was
> du mit Stack meinst verstehe ich gerade nicht ganz. Aber beim PC
> funktioniert's doch auch 8-)

Nein Christoph, einen PC kann man wirklich nicht mit einem AVR 
vergleichen, da er keinen linearen Adressraum hat. Schau mal nach 
"von-Neumann" und "Harvard"-Architektur bei wikipedia.

Eine Idee wäre allerdings möglich: Ein ausgefeilter Bootloader der eine 
SD-Karte lesen kann (FAT) und ein Display und Steuertasten. Dann könnte 
man via Bootloader eine Anwendung (hex oder bin-file) von der Karte 
lesen und starten (=in den Flash kopieren). NAch dem Reset startet 
wieder der Bootloader. Das fände ich durchaus praktikabel. Allerdings 
würde das den Bootloader etwas aufblähen, bei großen Controllern aber 
kein Problem.

Christoph P. schrieb:
> Problem, richtig. Möchte ich aber zwei Anwendungen auf dem µC haben und
> zwischen diesen Anwendungen mittels des Bootloaders wählen können, dann
> muss ich bei (dementsprechend großen) Firmwares irgendwann auch mal in
> den Speicherbereich >64 KB hineinspringen können. Dies würde ich gern so
> "dynamisch" wie möglich machen, in dem die Startadressen der Anwendungen
> aus den HEX-Dateien gelesen, gespeichert und bei Bedarf aufgerufen
> werden.

Wenn du mal genauer darüber nachdenkst, dann macht es keinen Sinn, auf 
einem AVR mehr als 1 Anwendung zu haben und per Bootloader umzuschalten.

1 AVR == 1 Anwendung

zb stimmen alle Interrupt Vektoren nicht. zb landet Applikation 2 in 
Applikation 1, wenn es selber einen Sprung nach 0000 macht. Zb muss die 
2.te Applikation für einen ganz anderen Speicherbereich gelinkt sein 
etc. etc.

Die ganze Thematik kannst du getrost vergessen.
Wenn jemand wirklich 2 vorhandene Applikationen in eine verschmelzen 
will, dann muss er das auf Code Ebene machen und sich selbst um die 
ganze kleinen Feinheiten kümmern. Zum SChluss steht er dann wieder mit 
nur 1 Applikation da, die vom Bootloader ins Flash gebrannt wird und bei 
0x0000 startet.

> Wenn du mal genauer darüber nachdenkst, dann macht es keinen Sinn, auf
> einem AVR mehr als 1 Anwendung zu haben und per Bootloader umzuschalten.
>
> 1 AVR == 1 Anwendung

Um genau zu sein, geht es mir auch mehr um die Möglichkeit eine Art 
Firmware-Update durchführen zu können und weniger darum, zwei wirklich 
verschiedene Anwendungsbereiche abzudecken. Also eher 1 AVR != 1 
Firmware-Version

> zb stimmen alle Interrupt Vektoren nicht. zb landet Applikation 2 in
> Applikation 1, wenn es selber einen Sprung nach 0000 macht. Zb muss die
> 2.te Applikation für einen ganz anderen Speicherbereich gelinkt sein
> etc. etc.

Vielleicht gehe ich an die Sache etwas zu blauäugig ran. Aber vielleicht 
kannst du ja noch mal genauer auf die Punkte eingehen. Das Linken in den 
gewünschten Speicherbereich ist ja kein Problem. Aber warum sollte 
Anwendung 2 an die Stelle 0x0000 springen (außer Watchdog löst aus 
o.ä.)? Das Auswählen zwischen den Anwendungen wird ja durch den 
Bootloader übernommen. Am wenigsten Ahnung habe ich derzeit von den 
angesprochenen Problemen mit den Interrupt-Vektoren.
Am Beispiel der Testanwendung aus dem Tutorial gesagt: Ich habe die 
gleiche Anwendung in die Speicherbereiche ab 0x00000, ab 0x00100 und ab 
0x10000 gelinkt und per Bootloader geflasht. Das heißt: Ich kann vom 
Bootloader in alle drei Anwendungen springen und von denen wieder in den 
Bootloader. Warum sollte das mit größeren Anwendungen nicht 
funktionieren? Danke schon mal!

> Eine Idee wäre allerdings möglich: Ein ausgefeilter Bootloader der eine
> SD-Karte lesen kann (FAT) und ein Display und Steuertasten. Dann könnte
> man via Bootloader eine Anwendung (hex oder bin-file) von der Karte
> lesen und starten (=in den Flash kopieren). NAch dem Reset startet
> wieder der Bootloader. Das fände ich durchaus praktikabel. Allerdings
> würde das den Bootloader etwas aufblähen, bei großen Controllern aber
> kein Problem.

Die ganze Geschichte am Ende über einen externen Speicher (egal ob 
SD-Karte oder was auch immer) zu lösen ist auch angedacht, aber für eine 
schnelle Testlösung erstmal etwas zu viel.

Christoph P. schrieb:

> Vielleicht gehe ich an die Sache etwas zu blauäugig ran. Aber vielleicht
> kannst du ja noch mal genauer auf die Punkte eingehen. Das Linken in den
> gewünschten Speicherbereich ist ja kein Problem. Aber warum sollte
> Anwendung 2 an die Stelle 0x0000 springen

Weil du als Bootloader Programmierer keine Kontrolle darüber hast, 
welche Schweinereien dein Anwendungsprogrammierer macht, die du nicht 
verhindern kannst.

wer will mich daran hindern zu schreiben

1

int main()

2

{

3

  void (*func)();

4

  func = 0;

5

6

  func();

7

}

Dein Bootloader ganz sicher nicht :-)


> Bootloader übernommen. Am wenigsten Ahnung habe ich derzeit von den
> angesprochenen Problemen mit den Interrupt-Vektoren.

Das kannst du auch so einfach nicht lösen. Denn die Position der 
Interrupt Vektoren ist dir von der Hardware vorgegeben.

> Am Beispiel der Testanwendung aus dem Tutorial gesagt: Ich habe die
> gleiche Anwendung in die Speicherbereiche ab 0x00000, ab 0x00100 und ab
> 0x10000 gelinkt und per Bootloader geflasht.

Na dann mach mal in deine Anwendung eine ISR rein und sieh nach welche 
angesprungen wird, wenn App3 läuft und der Interrupt auftritt

So, ich hab mir die ganze Sache mit den Interrupt-Vektoren nochmal durch 
den Kopf gehen lassen. Zunächst mal habt ihr natürlich recht, dass die 
ISR-Vektoren immer am Anfang des Speicherbereichs stehen. Wenn der 
auszuführende Inhalt der ISRs bei allen geflashten Anwendungen gleich 
ist, dürfte die Ausführung ja kein Ding sein, oder?
Allerdings ist mir nicht ganz klar, warum der Rücksprung in die 
eigentliche Anwendung aus einer ISR ein Problem darstellt. Ist die 
Rücksprungadresse denn nicht im Programmzähler gespeichert bzw. von 
diesem abhängig? Woher weiß denn die ISR (bzw. der µC) nach der 
Codeabhandlung an welche Stelle im Flash gesprungen wird?
Also konkret: Was genau hindert mich daran, bei gleichen ISR-Inhalten, 
mehrere Anwendungen auf einem µC laufen zu lassen (mal abgesehen von 
Funktionszeigern auf bestimmte Speicheradressen und sonstigen 
programmiererspezifischen Unwegbarkeiten)?
Wie gesagt, externer Zwischenspeicher ist defintiv angedacht, aber es 
soll ja fix gehen ;)

Schade, dass mir noch keiner eine Antwort auf obige Frage geben konnte. 
Derweil hier mal noch fix eine Funktion die eine BIN-Datei in den 
Flashspeicher schreibt. Dabei wird vorher noch (wenn auch sinnfrei der 
Diskussion zu folge) die Startadresse abgefragt und anschließend die 
Größe der BIN-Datei eingegeben. Danach einfach nur noch die Daten 
zwischenspeichern und ab in den Speicher. Vielleicht interessierts ja 
jemanden.

1

/**

2

 * Parser for the received BIN-file content

3

 */

4

void parse_bin_input(uint16_t receivedHexChar)

5

{

6

#ifdef BIN_MODE

7

  static uint8_t hexCounter = 0;    // writing position of the HEX-buffer

8

9

  static bool_t binStartAddrFlag = FALSE,  // flag indicating whether application start address is known or not

10

        binSizeFlag = FALSE;    // flag indicating whether application size is known or not

11

12

#if (SPM_PAGESIZE > 255)  // AVRs with 128k or more flash-memory

13

  static uint16_t flashCounter = 0;  // writing position of the flash-data buffer

14

  static uint32_t binStartAddr = 0,  // start flash-address of the application

15

        binSize,        // size of the application in byte

16

        flashPage = 0;      // to be written flash-page

17

#else            // AVRs with less than 128k flash-memory

18

  static uint8_t flashCounter = 0;  // writing position of the flash-data buffer

19

  static uint16_t binStartAddr = 0,  // start flash-address of the application

20

        binSize,        // size of the application in byte

21

        flashPage = 0;      // to be written flash-page

22

#endif

23

24

  hif_putc(XOFF);

25

26

  if (binStartAddrFlag == FALSE && binSizeFlag == FALSE)

27

  {

28

    hexDataBuffer[hexCounter++] = (uint8_t) receivedHexChar;

29

    if (hexCounter == 5)

30

    {

31

      binStartAddrFlag = TRUE;

32

      hexCounter = 0;

33

      binStartAddr = hex2num(hexDataBuffer, 5);

34

      flashPage = binStartAddr - binStartAddr % SPM_PAGESIZE;

35

      hif_puts("Size of BIN-file in 20 Bit Hex-format (e.g. 01F40):");

36

    }

37

  }

38

39

  else if (binStartAddrFlag == TRUE && binSizeFlag == FALSE)

40

  {

41

    hexDataBuffer[hexCounter++] = (uint8_t) receivedHexChar;

42

    if (hexCounter == 5)

43

    {

44

      binSizeFlag = TRUE;

45

      hexCounter = 0;

46

      binSize = hex2num(hexDataBuffer, 5);

47

      hif_puts("BIN-file content:");

48

    }

49

  }

50

51

  else if (binStartAddrFlag == TRUE && binSizeFlag == TRUE)

52

  {

53

    hif_putc('.');

54

    flashDataBuffer[flashCounter] = (uint8_t) receivedHexChar;

55

    flashCounter++;

56

57

    // buffer full => write page

58

    if (flashCounter == SPM_PAGESIZE)

59

    {

60

      hif_puts("P\n\r");

61

      //program_page((uint16_t) flashPage, flashDataBuffer);

62

      program_page(flashPage, flashDataBuffer);

63

      memset(flashDataBuffer, 0xFF, sizeof(flashDataBuffer));

64

      flashCounter = 0;

65

      flashPage += SPM_PAGESIZE;

66

    }

67

68

    // end of file => write remaining data

69

    else if (flashPage + flashCounter == binSize)

70

    {

71

      hif_puts("P\n\r");

72

      //program_page((uint16_t) flashPage, flashDataBuffer);

73

      program_page(flashPage, flashDataBuffer);

74

      memset(flashDataBuffer, 0xFF, sizeof(flashDataBuffer));

75

      flashCounter = 0;

76

      flashPage = 0;

77

      binStartAddrFlag = FALSE;

78

      binSizeFlag = FALSE;

79

      bootState = BOOT_STATE_EXIT;

80

    }

81

  }

82

83

  hif_putc(XON);

84

#endif  // BIN_MODE

85

}

Hallo zusammen,
Die Sache mit den Interruptvektoren und mehreren Firmwares auf einem 
Chip hat mich nun doch noch nicht in Ruhe gelassen.
Angenommen ich reserviere pro forma ab Adresse 0x0000 einen 
Speicherbereich in der Größe aller theoretisch möglichen 
Interruptvektoren. Ein vollständiges Image (inkl. Interruptvektoren) 
beider Firmwares befindet sich im Flash (im Speicherbereich entsprechend 
platziert mit den Linker-Flags im Makefile). In den reservierten 
Speicherbereich kopiere ich dann die Interrupttabelle der Anwendung, die 
ich gerade nutzen möchte. Da die Sprungziele m.M.n. absolute Adressen 
sind, müsste das doch funktionieren, oder? So kann man mittels 
Bootloader verschiedene Firmwares im Speicher platzieren und auch 
auswählen.
Ein unerwarteter Sprung zu 0x0000 würde somit auch wieder in der vorher 
verwendeten Anwendung enden.
Hoffe meine Gedankengänge sind nicht allzu wirr ;)

Frage an die Bootloader Gemeinde:

Ich möchte für ein Projekt einen Bootloader verwenden, um
Softwareupdates zu ermöglichen.
Jedoch sind die bisher verwendeten Möglichkeiten um den Bootloader in
den Updatemodus zu versetzen bei mir nicht möglich. Ich kann also nicht
den Taster oder die typischen 2 Warte sekunden bei mir einbauen.

momentan habe ich folgendes umgesetzt:

Nach dem Start checkt der Bootloader wie er gestartet wurde, in dem er
das Reset Register ausliest.
Wurde der Controller normal gestartet, so wird das bisherige Programm
aus dem EEProm geladen.
Wurde der Controller durch einen Hardwarereset neu gestartet, so
bedeutet es, dass eine neue Firmware als update kommt. Der Hardwarereset
wird durch die aktuelle Firmware ausgelöst, meist über einen Befehl von
der RS232 Schnittstelle.
Funktioniert so auch richtig gut.

Jedoch kann ich so keinen Watchdog benutzen (da der Bootloader sonst
jedesmal eine neue Firmware erwarten würde) was mir auch nicht recht
ist, da ich den Controller in einer relativ kritischen Anwendung nutze.

Ist folgendes möglich?

Kann ich zum speichern der Updateinformation auch ein Byte im EEprom des
Controllers nutzen? Es muss dabei garantiert sein, dass der Bootloader
und die Firmware auf die selbe SPeicherzelle zugreifen.
ist dsa möglich?

schon mal Vielen Dank

Martin J. schrieb:
> Kann ich zum speichern der Updateinformation auch ein Byte im EEprom des
> Controllers nutzen? Es muss dabei garantiert sein, dass der Bootloader
> und die Firmware auf die selbe SPeicherzelle zugreifen.
> ist dsa möglich?

Natürlich, wieso auch nicht?
Wie, steht bspw. hier: 
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#EEPROM

Hallo,

ich bin dem Tutorial gefolgt und habe versucht den Bootloader zum laufen 
zu bekommen.
Das Problem ist, dass die Hex-Datei nicht 1796 Byte sondern 2520 Byte 
groß ist. Hier einem mal die Ausgabe von Win-AVR beim kompletten 
Rebuild:

1

Build started 12.12.2010 at 21:52:31

2

avr-gcc  -mmcu=atmega128 -Wall -gdwarf-2 -std=gnu99          -DF_CPU=14745600UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT Bootloader.o -MF dep/Bootloader.o.d  -c  ../Bootloader.c

3

avr-gcc  -mmcu=atmega128 -Wall -gdwarf-2 -std=gnu99          -DF_CPU=14745600UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT uart.o -MF dep/uart.o.d  -c  ../uart.c

4

avr-gcc -mmcu=atmega128 -Wl,-Map=Bootloader.map Bootloader.o uart.o     -o Bootloader.elf

5

avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature  Bootloader.elf Bootloader.hex

6

avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex Bootloader.elf Bootloader.eep || exit 0

7

avr-objdump -h -S Bootloader.elf > Bootloader.lss

8

9

AVR Memory Usage

10

----------------

11

Device: atmega128

12

13

Program:    2502 bytes (1.9% Full)

14

(.text + .data + .bootloader)

15

16

Data:        352 bytes (8.6% Full)

17

(.data + .bss + .noinit)

18

19

20

Build succeeded with 0 Warnings...

Hat jemand ne Idee wo die ca. 700 Byte geblieben sind?

Danke

Felix

Hallo Felix,

nein das ist mir schleierhaft. Die Beispiele wurden mit einem Atmega88 
getestet. Da der Atmega128 aber einen genügend großen Bootloaderbereich 
hat, sollte es trotzdem gehen (nach richtiger Fuse-Konfiguration).

Hast du es mal ausprobiert?

Mir ist doch noch was eingefallen:
Evtl. bindet die UART library (uart.c und uart.h) etwas mehr Code ein. 
Im der Library von Peter Fleury wird der Prozessortyp ermittelt und 
entsprechend angepasste Funktionen eingebunden. Da der Atmega128 ja 
meherer UARTs hat, wird wohl mehr Code bzw. zusätzliche eingebunden 
werden.

Ich denke das ist des Rätsels Lösung.

Stell doch im Kompiler mal Spaßenshalber den Atmega88 ein und kompiliere 
es, mal sehen wir groß der Code da wird....

Hallo!
Ich habe versucht, den Bootloader auf einem DVK90CAN1 umzusetzen. Da der 
uC AT90CAN128 von Peter Fleurys UART nicht unterstützt wird, habe ich 
die UART mit FIFO von Peter Dannegger genommen. Das Projekt wird mit dem 
AVR Studio erstellt und erfolgreich kompiliert. Die Verbindung zu einem 
Terminalprogramm klappt ebenfalls vorzüglich (Danke, Peter!).
Nun aber zu meinem Problem: Wenn ich das Programm nach Anweisung in den 
Bootloaderbereich verschiebe durch Setzen der Linker-Option
(hier -Ttext=0x1E000) und "Verbiegen" der Interrupts, passiert nichts. 
Mit dem Autor des Artikels habe ich schon konferiert, aber er ist 
ratlos.
Welcher Schalter muß noch umgelegt werden?
Helene

Also:
Ein Programm, das compiliert, geflasht und ausgeführt wird, läuft 
erwartungsgemäß (keine Interrupts, nur "pollen").
Das Verschieben auf eine andere Anfangsadresse im Bootloaderbereich oder 
auch nur um ein paar words (na klar, compiliert, etc...) läuft nicht.
Kann mir wirklich keiner einen Tip geben?????
Helene

Hallo Helene,

wahrscheinlich hast Du das gleiche Problem wie ich:
Der Compiler erzeugt eine falsche Interrupt-Sprungtabelle:
0001f000 <__vectors>:
   1f000:  0c 94 72 f8   jmp  0x1f0e4  ; 0x1f0e4 <__ctors_end>
   1f004:  0c 94 91 f8   jmp  0x1f122  ; 0x1f122 <__bad_interrupt>
   1f008:  0c 94 91 f8   jmp  0x1f122  ; 0x1f122 <__bad_interrupt>
   1f00c:  0c 94 91 f8   jmp  0x1f122  ; 0x1f122 <__bad_interrupt>
   1f010:  0c 94 91 f8   jmp  0x1f122  ; 0x1f122 <__bad_interrupt>
...
Die jmp's sind alle 4, und nicht nicht, wie notwendig, 2 Byte.

Ich habe bis jetzt noch keine Möglichkeit gefunden, dass die 
Vektortabelle korrekt erzeugt wird (WinAVR 20100110: Optimize for size 
(-Os), -fno-jump-tables oder auch -mshort-calls --> keine Auswirkung).

Vielleicht weiß jemand eine Möglichkeit....

Gruß,
Gunter

Gunter Heuckeroth schrieb:
> Die jmp's sind alle 4, und nicht nicht, wie notwendig, 2 Byte.

Dann hast du wohl beim Linken den falschen Controller angegeben.

Hallo Stefan,

also, dann benutzt AvrStudio + Eclipse, wenn beim Linken 
"-Ttext=0x1F000" angegeben ist, einen anderen Controller als wenn diese 
Option nicht angegeben ist....

Hast Du es selbst mal probiert?

Gunter

Gunter Heuckeroth schrieb:
> "-Ttext=0x1F000"

Du benutzt also einen Controller mit 128k Flash. Wie kommst du darauf, 
dass die Vektoren 2 Bytes lang sein müssen? Die sind bei deinem 
Controller mit 100%iger Sicherheit 4 Bytes (2 Words) groß.

Hallo Stefan,

danke für die Anregung...
Du hast recht!

Ich bin auf die unterschiedliche Adressdarstellung hereingefallen 
(Datenblatt -> Wort-Adressen; GCC-Listing -> Byte-Adressen).

(Geistesblitz....)
Das heißt, für einen ATMEGA2560 muß ich dem Linker als Adresse 0x3E000 
angeben (Byteadresse!) und nicht 1F000 (Wortadresse!)...

Arrghhh...

Dann klappt's vielleicht jetzt auch mit den Interrupts...

Nochmals danke, werde ich jetzt gleich ausprobieren....

Gunter

Hallo Unwissender ;-)

Nach einem kurzen Überfliegen des Datenblattes des 8515:
Es gibt kein "Boot"-Flash-Bereich, in dem ein Bootloader stehen könnte.
Das Teil kann nur per "parallelem" Programming oder "seriell" geflasht 
werden.

Gruß,
Gunter

Hallo Mario,
ich hab bestimmt was noch nicht verstanden: was ich im Code nicht sehe 
ist folgendes: wenn eine geparste Adresse aus der momentan aktuellen 
Flash-Page herausführt (also ein Adresssprung im hex-File, was ja 
möglich ist), müsste dann nicht erst die (gegebenenfalls nur teilweise 
ausgefüllte) "alte" flash page geschrieben werden und dann eine neue 
flash-page Adresse erzeugt werden? Oder einfach gefragt: funktioniert 
der Code auch wirklich bei einem nicht linear durchgehend beschriebenen 
Flash-Speicher? Im code sehe ich nur, dass der Flash bei vollem Puffer 
oder bei hexRecType = 1 (Ende des Files) geschrieben wird.
Konkret sehe ich das Problem, wenn ich ans Ende des Flashspeichers 
direkt vor dem Bootcode z.B. noch eine Versionsnummer eintragen will, 
wie das in den SD-card- Bootloadern, die mit Binärdateien arbeiten, oft 
üblich ist.  Das kann ich ja mit -section-start = xxxxxxx als 
linker-flag erreichen.
Ich will das für einen Xmega128 machen und muss dazu natürlich auch in 
den extended segment address-Bereich (währen mein restlicher code in den 
64K-Bereich passt). Die letzen vier Zeilen des hex-files sehen dann so 
aus:
:10092C0067000000000200000000650300000000EA  //letzte Zeile aus 
64K-space
:020000021000EC                              //extended address
:08FFF8007856341255AA0000EE                  //code ab addr. 0x1FFF8
:00000001FF                                  //file ende, hexRecType 1
Bei der Arbeit mit Binärfile alles kein Problem, da wird ja brav der 
gesamte flash durchgehend bis zur obersten verwendeten Adresse 
abgespeichert.
Über eine Aufklärung würde ich mich freuen.
Grüße,
Karl
@CheKr: Properties, Toolchain, AVR/GNU C Compiler, Symbols. Unter -D 
defined symbols mit dem grünen "+" Symbol F_CPU= xxxxxxUL eintragen

Karl Jacobs schrieb:
> Hallo Mario,
> ich hab bestimmt was noch nicht verstanden:

Ich würde sagen: Das hast du im Code richtig gesehen.

und wenn man dann nur so einen kleinen "Brocken" in den Flash schreibt, 
sollte man vielleicht vorher lieber die originale flash page erst mal in 
den Puffer laden, damit man nichts verändert, was man gar nicht 
verändern will, wenn man die page wieder zurückschreibt. So macht's der 
kavr zum Beispiel.
Karl

und hier wäre dann mein Vorschlag, die oben beschriebenen Probleme zu 
beheben, als Erweiterung von Marios Code, mit Kommentaren. Der Code ist 
aber ungetestet, ich weiß gar nicht, ob so was hier erlaubt ist... Er 
sollte jetzt auch hex-Files schlucken, in dem die Adressen kreuz und 
quer gehen.
Grüße,
Karl

eine Zeile war verrutscht.
Karl

Hallo Karl,
du hast richtig gelesen. Adresssprünge und Code >64K wurden bisher nicht 
berücksichtigt. Dies ist auch am Ende des Tutorials vermerkt.
Mario

wen es interessiert: im Paralleluniversum
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=953604#953604
habe ich den dort ursprünglich veröffentlichten code für einen Xmega 
Bootloader, der einen hex-file von einer SD-Karte einliest, so 
umgearbeitet, dass er tatsächlich auch für flash code im Bereich >64k 
arbeitet und eine Versionskontrolle erlaubt. Getestet mit XMega128A1 und 
FAT16.
Karl

Die downloads sind nur sichtbar, wenn man bei avrfreaks angemeldet ist, 
was aber ja keine Hürde sein sollte. Ich fand es dem Autor bei 
avrfreaks, dessen Programm ich erweitert habe, unfair gegenüber, den 
code auch hier anzuhängen. Ich lasse mich vom Moderator aber gerne eines 
besseren belehren bzw. meinen Post hier löschen.
Karl

no member of AVRFreaks.net schrieb:
> Sign Up? -> Fehlanzeige...

Lieber Gast, ich verstehe diese Meldung zwar nicht, aber wenn Du hier 
angemeldet wärest, könntest Du mir eine Nachricht schicken und bekämst 
den code direkt von mir. Ich möchte allerdings nicht das Forum hier 
vollmüllen, das ist daher mein letzter post zu diesem Thema.