Forum: Mikrocontroller und Digitale Elektronik Bootloader und App in einem ELF


von Wolfram (Gast)


Lesenswert?

Hi,

Hat jemand ein Makefile, welches die Applikation und den Bootloader in 
einem ELF file erzeugt?

von Peter D. (peda)


Lesenswert?

Du kannst nicht 2 eigenständige Programme gemeinsam compilieren.

Du kannst höchstens beide Hex-Files aneinander pappen (Enderecord des 
einen entfernen und dann das andere dahinter).


Peter

von Wolfram (Gast)


Lesenswert?

richtig ich will sie auch nicht gemeinsam compilieren, sondern beide 
nach dem Linken zusammenfassen. Dazu benötige ich den genauen Befehl 
(avr-objcopy?).
Ich ging davon aus das es eine Standardlösung gibt und jemand das schon 
in seinem Makefile benutzt. Deshalb die Frage nach einem Makefile als 
Vorlage.

von hahgeh (Gast)


Lesenswert?

Eine zum vielleicht Thema passende Frage:

Man könnte doch auch erst den Bootloader programmieren, und dann die 
Applikation (ohne Chip Erase) darüberschreiben. Dann müßte doch der 
Bootloader erhalten bleiben (falls die Anwendung nicht zu groß ist :)?

MfG hahgeh

von Peter D. (peda)


Lesenswert?

Wolfram wrote:
> richtig ich will sie auch nicht gemeinsam compilieren, sondern beide
> nach dem Linken zusammenfassen. Dazu benötige ich den genauen Befehl
> (avr-objcopy?).

Das Make dient zum Compilieren genau eines Programms, mehr nicht.
Nach dem Erzeugen des Outputfiles ist seine Sache erledigt.


> Ich ging davon aus das es eine Standardlösung gibt

Die Standardlösung ist die, daß man nur den Bootloader reinbrennt und 
schreibschützt.
Und die Applikation eben per Bootloader.

Es ist unsinnig bei Änderungen der Applikation jedesmal den Bootloader 
neu mit zu brennen. Bzw. dann hätte man ja gar keinen Bootloader 
gebraucht.


Peter

von Wolfram (Gast)


Lesenswert?

Das Make dient zum variablen Benutzen der Programme Compiler Linker 
umwandeln in Hex etc. andere Leute benutzen batch dateien make ist 
flexibler.
Ich kann mit einem Makefile auch 2 Programme compilieren oder auch den 
ganzen Rechner löschen...

Die Standardlösung ist, man erzeugt ein Hexfile das beides enthält 
Bootloader und Applikation und gibt dieses File seinem Distributor damit 
er die Chips gleich geflasht ausliefert. Das spart zeit bei der 
Produktion.
Ich möchte wissen wie ich die Applikation und den Bootloader in ein 
Hexfile mit den Boardmitteln des GCC/WinAVR bekomme. Ich vermute 
avr-objcopy kann sowas. Ob ich den Aufruf im Makefile dann zur 
Bequemlichkeit einfüge mal sehen. (Der andere Weg wäre beides zu flashen 
und dann auszulesen.)

von Gast (Gast)


Angehängte Dateien:

Lesenswert?

Also ich mache es immer so. Die Progrämmchen sind überall zu finden.

von Peter D. (peda)


Lesenswert?

Wolfram wrote:

> Ich kann mit einem Makefile auch 2 Programme compilieren oder auch den
> ganzen Rechner löschen...

Make ist ein Script, Du kannst auch 100 Programme jedes für sich 
hintereinander übersetzen, aber eben nicht verwursten.

> Die Standardlösung ist, man erzeugt ein Hexfile das beides enthält
> Bootloader und Applikation und gibt dieses File seinem Distributor damit
> er die Chips gleich geflasht ausliefert. Das spart zeit bei der
> Produktion.

Für die Produktion muß man doch nicht ständig Make aufrufen, da reicht 
es die Files wie bereits oben beschreiben aneinander zu hängen. Geht mit 
jedem Texteditor.


> Ich vermute
> avr-objcopy kann sowas.

Warum sollte es ?
Es wandelt nur ein Format in ein anderes um.
Es heißt ja schließlich nicht avr-objmerge.
Zusammen linken kann nur der Linker etwas.


> Ich möchte wissen wie ich die Applikation und den Bootloader in ein
> Hexfile mit den Boardmitteln des GCC/WinAVR bekomme.

Garnicht, Du brauchst extra Tools, z.B. wie Gast es beschreibt.


Peter

von Wolfram (Gast)


Lesenswert?

Die Hexvariante hat den Nachteil das ich es nicht debuggen kann.
Was gibt es für möglichkeiten Bootloader mit eigener Interrupttabelle 
und Applikation in einem Projekt zu halten, so daß es debuggbar bleibt?
Hat da jemand ein Projektgerüst?

Bisher kenne ich es nur so, daß am Schluß die textsection auf eine 
andere Adresse velegt wird.

von Peter D. (peda)


Lesenswert?

Wozu willst Du beides gleichzeitig debuggen ?

Es läuft ja immer nur ein Programm.
Der Bootloader, um ne neue Applikation zu brennen oder die Applikation, 
um was zu machen.


Wir haben auch ne Anwendung, wo die Applikation was in den Flash 
schreiben muß und damit das Problem, daß dann der Bootloader das 
Speicherabbild der Applikation zerstört.

Die Lösung sieht so aus, daß die Applikation die zu schreibenden Daten 
an den Bootloader übergibt und diesen startet. Der brennt dann die Daten 
und macht einen Watchdogreset.
D.h. die Applikation startet danach wieder neu und baut sich auch ihr 
Speicherabbild neu auf.


Man muß immer daran denken, das es 2 völlig eigenständige Programme 
sind, die voneinander nichts wissen und daher auch nie gleichzeitig 
laufen dürfen.

Man müßte quasi 2 Debugger starten, für jedes Programm einen.
Ich glaube aber kaum, daß es für den AVR einen Debugger gibt, der in 2 
Instanzen laufen kann.


Peter

von Wolfram (Gast)


Lesenswert?

>Die Lösung sieht so aus, daß die Applikation die zu schreibenden Daten
>an den Bootloader übergibt und diesen startet. Der brennt dann die Daten
>und macht einen Watchdogreset.

und genau sowas will ich am Gerät debuggen können...
teilweise Breakpoints im App Bereich und im Bootloaderbereich

Ich muß leider (eigentlich nicht leider) in Wochenende, bis Montag

von Knut (Gast)


Lesenswert?

Debuggen? Breakpoints? Mach doch einfach ein printf(...) an den 
geeigneten Stellen und hau die Meldungen über UART raus, oder sehe eine 
LED vor. Das zeilenweise durchgehen von Code braucht man doch eigentlich 
nie, es sei denn, man kann gar nicht programmieren. Was aber bei dir ja 
nicht zutrifft.

von Wolfram (Gast)


Lesenswert?

>Debuggen? Breakpoints? Mach doch einfach ein printf(...)
Warum versucht ihr um dieses Problem herumzureden?
Gerade der Übergang vom Bootloader zur Applikation, oder von Applikation 
zu Bootloader sind kritische Punkte, wo viele Fehlerquellen lauern die 
einen "unsauberen" Reset durch das vergessene Abschalten eines Timers 
etc, oder durch eine vorinitialisierung im Speicher möglich machen. 
Gerade an dem Punkt ist die Ausgabe mit printf aufgrund fehlender 
Initialisierung sehr schlecht möglich und auch kein Beweis, das in 
Wirklichkeit nicht 10 ungewollte Resets dazwischen sind.
Da ist die Kontrolle per JTAG im Quellcode (C) schon wünschenswert.

von Stefan K. (_sk_)


Lesenswert?

Hallo Wolfram,

dass Du beide Teile - Applikation UND Bootloader - gleichzeitig auf 
Quelltextebene debuggen kannst, kann ich mir nicht vorstellen. Allein 
dass 2 main() vorhanden sind, wird AVRStudio nicht auf die Reihe 
bekommen.

Die neueste AVRStudio-Version kann aber immerhin mit verschiedenen 
Flash-Segmenten umgehen (früher wurden alle Flash-Segmente <> .text im 
.elf File ignoriert bzw. nicht in den mc geladen).

Vielleicht ist das für Dich eine Lösung:
In der Applikation ein Array ab der Bootloader-Adresse anlegen, in das 
die Binärdaten des Bootloader geschrieben wurden. Dazu brauchst Du ein 
Tool, das Binär- oder Hexdaten in ein Array (in einem C-File) umwandelt. 
Bei Font- und Graphikkonvertern habe ich sowas schon mal gesehen.
Damit kannst Du beide Programme zusammen testen, den Bootloader zwar nur 
im Disassembler-Mode, aber immerhin.
Das funktioniert erst mit der neuesten AVRStudio-Version!

Schön wäre es, wenn AVRStudio eine Option hätte, das Flash nur teilweise 
zu überschreiben.

Viele Grüße, Stefan

von Wolfram (Gast)


Lesenswert?

Die "umständlichen" Lösungen die ihr vorschlagt, sind mir auch schon in 
den Sinn gekommen. Es ging mir um die Frage ob es auch einen sauberen 
Weg gibt, dies in Avrstudio/GCC zu erreichen. Bevor ich es selber mache 
wollte ich wissen, ob jemand so etwas schon gemacht hat und eine Vorlage 
hat oder die Probleme dabei schildert.

Mich interressiert ob es da grundsätzliche Probleme gibt, sowas ala
Das geht nicht weil avrgcc/avrlibc nur eine Interrupttabelle 
unterstützt!
oder nur einen .init teil etc.

Wahrscheinlich wäre der Thread im Forum GCC richtiger positioniert.

von Peter D. (peda)


Lesenswert?

Wolfram wrote:

> Mich interressiert ob es da grundsätzliche Probleme gibt

Na überleg dochmal, warum sollte sich denn hier jeder mit Alternativen 
abmühen, wenn es ginge.

Du kannst keine 2 verschiedenen Programme (2 * main) mit einem Debugger 
debuggen, Punkt.




Peter

von Wolfram (Gast)


Lesenswert?

>Du kannst keine 2 verschiedenen Programme (2 * main) mit einem Debugger
>debuggen, Punkt.
Ok Schritt für Schritt...
Der Bootloader muß als erstes aktiv werden und entscheidet ob er im 
Bootloader bleibt oder in die App weitergeht. somit muss die App nicht 
zwangsläufig "main" heißen.
Stellt sich die Frage: Wie definiere ich 2 Interrupttabellen für Boot 
und App?

von Stefan K. (_sk_)


Lesenswert?

>Stellt sich die Frage: Wie definiere ich 2 Interrupttabellen für Boot
>und App?

Es hängt nicht nur an der IR-Tabelle. Die ist wahrscheinlich noch das 
kleinere Problem. Auch die ganze Initialisierung etc., die Dir der 
Compiler bzw. Linker abnimmt, muss für 2 Programme gemacht werden. Und 
das kann er mit Sicherheit nicht.

Eine Lösung für Dein Problem muss also nach dem Compiler/Linker greifen, 
d.h. auf elf-File-Ebene. Ob sich 2 Applikationen innerhalb eines 
elf-Files verheiraten lassen, weiss ich nicht. Selbst wenn es 
funktioniert, ist die Frage, ob AVRStudio mit dem Ergebnis später 
umgehen kann. Wie oben gesagt: mit Flash-Sections <> .text kann 
AVRStudio gerade mal seit 2 Monaten umgehen.

Ich benutze selbst den jtag-Debugger und habe im Prinzip dieselben 
Probleme wie Du. Von daher ist mein Lösungsvorschlag oben nicht aus der 
Luft gegriffen.

Viele Grüße, Stefan

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
Noch kein Account? Hier anmelden.