Forum: Mikrocontroller und Digitale Elektronik Bootloaderbereich beim Flashen mit JTAG nicht überschreiben?


von AVRli (Gast)


Lesenswert?

Hallo,

ist es möglich den Bereich, in dem sich der Bootloader befindet, bei 
einem Flash Vorgang (Daten in den Applicationsbereich schreiben) NICHT 
zu überschreiben/löschen?

Ich habe mir für mein ATmega 644 Projekt einen Bootloader geschrieben. 
Wenn ich nun aber an der Applikation weiter entwickle, fliegt der immer 
wieder raus und die Platine ist dann wieder ohne Bootloader. Das möchte 
ich vermeiden, ist das möglich?

Nutze:
- Atmel Studio 7
- JTAG MKII
- ATmega 644

Danke Euch!
Gruß AVRli...

von Horst S. (Gast)


Lesenswert?

Deine App wird nachher NUR NOCH vom Bootloader in den Käfer beschrieben.
Alles paletti?

von Adam P. (adamap)


Lesenswert?

Horst S. schrieb:
> Deine App wird nachher NUR NOCH vom Bootloader in den Käfer beschrieben.
> Alles paletti?

Ist für die Entwicklungszeit nicht ganz zufriedenstellend.

Ja du kannst das unter den Projekteinstellungen ändern, also in den 
deines Programms nicht beim Bootloader.

Da müsstest du sagen, nur den Flash Bereich des Prog. löschen. Dann 
nutzt er den Offset den du angegeben hast und lässt dein 
Bootloaderbereich unangetastet.

edit:
Bin grad nicht am PC sonst würd ich dir nen Screenshot machen.

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

AVRli schrieb:

> ist es möglich den Bereich, in dem sich der Bootloader befindet, bei
> einem Flash Vorgang (Daten in den Applicationsbereich schreiben) NICHT
> zu überschreiben/löschen?

Nicht beim Programmieren von "aussen" bzw. höchstens in dem seltenen 
Ausnahmefall, dass kein Bit im Applikationsbereich von 0 auf 1 
modifiziert werden muss.

Im Normalfall ist das aber nötig, weswegen vor dem Programmieren von 
außen der Flash gelöscht (also komplett auf Einsen gesetzt) werden muss, 
was unwiderruflich auch den Bootloader entsorgt.

Ein Bootloader hat diese Beschränkung nicht, denn er ist nicht darauf 
angewiesen, den gesamten Flash zu löschen, sondern kann das 
(Lösch-)seitenweise tun.

Da stellt sich dann die Frage: Wenn du einen Bootloader hast, dessen 
Aufgabe ja vor allem ein Update der Applikation(en) ist, warum benutzt 
du ihn dann nicht auch für genau den Zweck, für den er gedacht ist? Das 
würde doch dein Problem ganz unmittelbar und vollständig lösen...

von AVRli (Gast)


Lesenswert?

Adam P. schrieb:
> Ja du kannst das unter den Projekteinstellungen ändern, also in den
> deines Programms nicht beim Bootloader.

Das wäre wohl genau das, was ich suche.
Wenn Du die Zeit findet, wäre es toll mal ein Beisepiel zu zeigen.

Danke! :-)

c-hater schrieb:
> Da stellt sich dann die Frage: Wenn du einen Bootloader hast, dessen
> Aufgabe ja vor allem ein Update der Applikation(en) ist, warum benutzt
> du ihn dann nicht auch für genau den Zweck, für den er gedacht ist?

Ja es ist schon ein wenig die "Eier-Huhn-Frage" da muss ich Dir Recht 
geben.

Klar im fertigen Projekt ist das natürlich keine Frage WIE der µC 
programmiert wird. Ausschließlich über den Bootloader!

Nun zur Entwicklungszeit fänd ich es schon angenehm, wenn der Bereich 
beim einspielen der Application via JTAG eben nicht angefasst werden 
würde.

Gruß AVRli...

von c-hater (Gast)


Lesenswert?

AVRli schrieb:

> Ja es ist schon ein wenig die "Eier-Huhn-Frage" da muss ich Dir Recht
> geben.

Eigentlich nicht. Entweder, es ist schon ein Bootloader verfügbar, dann 
benutzt man einfach den zum Update der Applikation. Oder es ist keiner 
verfügbar, dann flasht man ihn halt von "aussen" (und ggf. im selben 
Rutsch die aktuelle Anwendung).

Es läuft eigentlich nur darauf hinaus, in der IDE den korrekten Weg für 
das aktuelle Erfordernis zu wählen (und natürlich vorher entsprechend 
einzurichten).

> Nun zur Entwicklungszeit fänd ich es schon angenehm, wenn der Bereich
> beim einspielen der Application via JTAG eben nicht angefasst werden
> würde.

Das ist einfach der falsche Grundansatz. Wenn du nur die Applikation 
einspielen willst, darfst du das halt einfach nicht via JTAG tun, 
sondern musst es über den Bootloader tun. Das ist schon alles. Wo ist 
das Problem?

von MeineZweiCent (Gast)


Lesenswert?

AVRli schrieb:
> Ja es ist schon ein wenig die "Eier-Huhn-Frage" da muss ich Dir Recht
> geben.
>
> Klar im fertigen Projekt ist das natürlich keine Frage WIE der µC
> programmiert wird. Ausschließlich über den Bootloader!

Der Bootloader ist gerade während der Entwicklung der Applikation 
interessant. Dann kannst du die App bequem per bootloader updaten ohne 
den controller via JTAG zu flashen.
Wenn die Applikation fertig entwickelt ist und es keine Updates mehr 
geben soll, kannst du den Bootlaoder in die Tonne treten. Denn du musst 
jeden neuen Chip den du bekommst sowieso per JTAG flashen, dann kannst 
du auch gleich die ganze applikation flashen.

von Bernd K. (prof7bit)


Lesenswert?

MeineZweiCent schrieb:
> Der Bootloader ist gerade während der Entwicklung der Applikation
> interessant. Dann kannst du die App bequem per bootloader updaten ohne
> den controller via JTAG zu flashen.

Der Bootloader ist gerade während der Entwicklung der Applikation
weniger interessant denn dort kann man die App bequem per JTAG updaten 
und debuggen. Erst in der Produktion oder für ein späteres 
Firmware-Update erweist sich ein Bootloader als nützlich.

von c-hater (Gast)


Lesenswert?

Bernd K. schrieb:

> Der Bootloader ist gerade während der Entwicklung der Applikation
> weniger interessant denn dort kann man die App bequem per JTAG updaten
> und debuggen. Erst in der Produktion oder für ein späteres
> Firmware-Update erweist sich ein Bootloader als nützlich.

Ja, klingt irgendwie logisch. Aber: wenn er während der Entwicklung 
nicht benötigt wird, dann schadet es doch auch nicht, wenn er garnicht 
vorhanden ist, oder? Wo also ist das Problem?

von MeineZweiCent (Gast)


Lesenswert?

Bernd K. schrieb:
> Der Bootloader ist gerade während der Entwicklung der Applikation
> weniger interessant denn dort kann man die App bequem per JTAG updaten
> und debuggen.

Kommt auf die Applikation an. Ich glaube nicht dass der TE mit seinem 
AVR Projekt in die große Produktion geht oder wahnsinnig viele Software 
updates on the fly via Bootloader aufspielen muss :D

von Peter D. (peda)


Lesenswert?

Idealer Weise sollte der Bootloader für die Applikation als nicht 
vorhanden erscheinen, d.h. in der Entwicklung per JTAG kann man den 
Bootloader ganz einfach weglassen. Der Code rauscht dann durch die 
0xFFFF durch, die quasi wie NOPs wirken, bis er auf Adresse 0x0000 
überläuft und die Applikation startet.
Will man aber testen, ob der Bootloader sich negativ auf die Applikation 
auswirkt, dann erzeugt man einfach ein HEX des Bootloaders, entfernt die 
letzte Zeile (Enderecord) und fügt ihn per Batch vor die Applikation 
ein.

von AVRli (Gast)


Lesenswert?

Ich möchte das meine Freunde ihre Hardware nicht immer zu mir schicken 
müssen, wenn ich etwas an der Applikation geändert habe.

Peter D. schrieb:
> Will man aber testen, ob der Bootloader sich negativ auf die Applikation
> auswirkt, dann erzeugt man einfach ein HEX des Bootloaders, entfernt die
> letzte Zeile (Enderecord) und fügt ihn per Batch vor die Applikation
> ein.

Genau das möchte ich überprüfen!
Ich könnte den den Bootloader so zu sagen auch jedes mal unten dran 
hängen, wenn ich die Applikation neu einschreibe?

Gruß AVRli...

von AVRli (Gast)


Lesenswert?

Habe es hin bekommen, kann nun meine Applikation Testweise mit 
Bootloader flashen.

Habe noch ein Problem mit dem Bootloader aber dazu mache ich lieber ein 
neues Thema auf...

Vielen Dank und schöne Grüße!
AVRli...

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.