STM32F7: Eigener Bootloader startet die Applikation nicht

Laspalmas schrieb:
> wenn ich debugge finde ich:
>                      addr: 0x8060104
>                      JumpAddress: 0x80602F5
>                      Jump_To_Application: 0x80602F5

Wenn deine Interrupttabelle bei 0x8060100 liegt, wirst du möglicherweise 
Probleme bekommen, wenn du die Flashtabelle nutzt (Alignment 0x200 oder 
so, je nach Derivate).

Laspalmas schrieb:
> was mich verwirrt ist: JumpAddress: 0x80602F5
> wie kommt der Compiler draut. Ist es überhaupt richtig?

Passt. An der Stelle steht die Adresse, wo du hinspringen sollst. Auch 
das Thumb bit ist bereits ordentlich gesetzt.

A. B. schrieb:
> Das würde heißen, nach JEDEM Reset startet zuerst der Booloader und
> der wiederum ggf. die Applikation? Dann ist das '+4' aber in der Tat
> zuviel, bzw. vielmehr die ganze Vektortabelle zuviel.

Das ist die Vektortabelle der Applikation.

tom schrieb:
> __set_PRIMASK(1); // disable all isr's
> JumpAddress = *(__IO uint32_t*) (0x08060200+4);
> Jump_To_Application =  (pFunction) JumpAddress;
> __set_MSP(*(__IO uint32_t*)0x08060200;
> Jump_To_Application();

Nur der Vollständigkeit halber:
Da der Stack umgebogen wurde, muss Jump_To_Application im Register 
liegen. Ist aber eigentlich immer der Fall. Aber wenn du am Verzweifeln 
bist check einfach mal diese Stelle im Assembler.

A. B. schrieb:
> 2. Vektortabelle verschieben (Vector Table Offset register auf
> 0x08060200)

Das ist diskutabel. Ich bin auch dafür, dass im Bootloader zu machen. 
Aber auf jedenfall gibt es regelmäßig derartige Einstellungen in der 
Applikation, die das Register zurücksetzen. An diese Stelle muss man 
genauso denken.

Laspalmas schrieb:
> aber immer noch das gleiche Problem.

Ich vermute das Problem in der Applikation, nicht im Bootloader.
Die üblichen Verdächtigen wie Umstellen der Vektortabelle wurden 
genannt.
Oft geht die Applikation auf davon aus, dass nach dem Reset die 
Interrupte enabled sind und gern disabled man diese im Bootloader.

Einfach mal die Applikation per Bootloader flashen und dann ohne Flashen 
die Applikation debuggen.

Laspalmas schrieb:
> wie kann ich das umgehen?

Nicht umgehen...
Ziel ist es, dass alles so ist wie am Ende, d.h. Bootloader im Flash, 
Applikation im Flash, ggf. Prüfdaten im Flash.
Aufpassen, dass man beim Debuggen nicht erased und flashed.

In diesem Zustand einfach die Applikation debuggen. Natürlich wird so 
erst der Bootloader durchlaufen und erst dann die Applikation.
Ich setze meinen erstne Breakpoint in den Resetvektor der Applikation, 
um zu sehen, dass alles wie erwartet anläuft.

Ab jetzt ganz normal debuggen.

Laspalmas schrieb:
> Vieeeeeelen Danke an Alle.
> Granz Großer Lob!
>
> Es lag an der Applikation genauer gesagt an HAL_Delay() die nicht mehr
> funktionniert (bis jetzt nicht. Ursache muss ich noch finden.
> Vielleicht liegt es an __set_PRIMASK(1): alle Interrupts abschalten).
> D.h. mit folgenden Code hat der Boot-Loader die Applikation gestartet:
>
>       __set_PRIMASK(1);
>       addr = GetApplicationStartAddress() + sizeof(APP_HEADER)+4;
>       JumpAddress = *(__IO uint32_t*) addr;
>       Jump_To_Application =  (pFunction) JumpAddress;
>       __set_MSP(*(__IO uint32_t*)(GetApplicationStartAddress() +
> sizeof(APP_HEADER)) );
>
>       Jump_To_Application();
>
>
> Vielen Dank noch mal.
> Laspalmas.

An der Stelle möchte ich noch auf eine sehr sehr gerne gemachte 
Denklücke hinweisen:

Da dein BL HAL_Delay() benutzt, aber über das Flash Layout jenseits 
seines Bereiches keinen Einfluss hat, muss der Code für HAL_Delay() im 
BL Bereich des Flashes sitzen.

So weit so gut. Interessant wird's nun aber, wenn deine App auch 
HAL_Delay() benutzt. Hier gibt es mehrere Implementationsvarianten:

1. Der Bootloader ist nicht ersetzbar. Dann darf die App statisch 
Informationen aus dem Linker Map file des BL nutzen, um absolut dort 
hinzuspringen. Geht natürlich nicht in die Andere Richtung...
2. Die App dupliziert den Code für HAL_Delay(). Das geht prinzipiell, 
ist aber mit grosser Vorsicht zu geniessen (manche HAL Funktionen 
benutzen geteilte globale Variablen, die dann logischerweise für BL und 
App an verschiedenen Stellen sitzen, was ein Anlass für sehr lange 
Debugsessions und ein Grund zur Freude für die Kaffeeindustrie sein 
kann). Ausserdem ist es nicht Sinn und Zweck der Sache, Code doppelt zu 
halten.
3. Dynamische Sprungtabellen, also ein indirektes 
Funktionsaufrufinterface zwischen BL und App. Im frei herunterladbaren 
Beispielcode zum Buch Kapitel 9 hast Du ein Beispiel wie man so etwas 
machen kann (nur falls Du das noch nicht in Betracht gezogen hast; es 
hat mich ca. 5 BL gebraucht, bis ich das so mit Allen Fallstricken und 
Randpoblemchen gerade gezogen habe). Funktioniert auch in beide 
Richtungen (also Aufrufe vom BL in Applikationsocde, was auf der ersten 
Blick schräg erscheint, aber zuweilen in Form von Callbacks sinnvoll 
sein kann).

Ruediger A. schrieb:
> 2. Die App dupliziert den Code für HAL_Delay(). Das geht prinzipiell,
> ist aber mit grosser Vorsicht zu geniessen

Bei mir sind Bootloader und Applikation völlig getrennte Projekte. Da 
sie nichts voneinander wissen, gibts auch keine Verwechslungen.

eagle user schrieb:
> Und wenn der Bootloader ein oder zwei Interrupts
> braucht, kann er die auch wieder abschalten bzw. das Modul resetten.

Prinzipiell hast du recht und wird wohl auch ST so sehen. Klassisch habe 
ich aber gelernt all den Wenn und Abers aus dem Weg zu gehen und die 
globalen Interrupte abzuschalten.
Und in diesem Fall auch erst wieder einzuschalten, wenn das Register für 
die Vectortable richtig gesetzt ist.

Guest schrieb:
> eagle user schrieb:
>> Warum möchte ich das?
>
> Weil du irgendwann vor dem Sprung in die Applikation die Interrupt
> Vektor Tabelle umstellst (VTOR). D.h. es kann passieren, das im
> Bootloader Interrupts auf der Interrupt Vektor Tabelle der Applikation
> laufen. Und das kann ganz gewaltig schief gehen.

Berücksichtige bitte die Aussage:

eagle user schrieb:
> kann er die auch wieder abschalten bzw. das Modul resetten.

Beim Sprung in die Applikation initialisierte Peripherie zu hinterlassen 
(die Interrupte auslöäsen könnte, wenn nicht abgeschaltet) ist 
vielleicht nicht ganz so gut.

Anm:
Ich bin auch ein Verfechter des Abschaltens der globalen Interrupte. 
Aber die Argumentation greift nicht.

Steffen R. schrieb:
> Ruediger A. schrieb:
>> 2. Die App dupliziert den Code für HAL_Delay(). Das geht prinzipiell,
>> ist aber mit grosser Vorsicht zu geniessen
>
> Bei mir sind Bootloader und Applikation völlig getrennte Projekte. Da
> sie nichts voneinander wissen, gibts auch keine Verwechslungen.
>

Doch doch, die gibt es, und genau das ist mein Punkt:

Wenn Du zwei komplett voneinander getrennte Instanzen von der HAL hast, 
können die nicht miteinander funktionieren, jedenfalls nicht solange Du 
die Standardimplementation benutzt.

Die Defaultimplementation der HAL unter ST registriert einen 
Timerinterruphandler, der eine globale Variable uwTick incrementiert, 
und HAL_Delay() berechnet lediglich solange die Differenz zwischen 
uwTick und dessen Stand bei Eintritt in HAL_Delay(), bis das gewünschte 
Delta überschritten wird.

Hast Du zwei verschiedene Instanzen der HAL, dann hast Du auch zwei 
voneinander unbhängige Instanzen von uwTick - aber vermutlich nur einen 
ISR (HAL_InitTick() benutzt zumindestens in der Standardimplementation 
nur einen Timer). Abhängig davon, "wessen" ISR mit dem Timer assoziiert 
ist, wird der eine oder der Andere Timer funktionieren, die Andere 
uwTick aber vermutlich niemals inkrementiert (was u.A. zu einem nie 
wiederkehrenden HAL_Delay() führt).

Und das ist nur die Spitze des Eishügels (für einen Berg ist es nun doch 
nicht komplex genug), denn die Prozessorfrequenz ist ebenfalls in einer 
globalen Variable abgelegt, nämlich SystemCoreClock - von der es besser 
keine zwei Instanzen geben sollte (weil nämlich die Clock in der Regel 
nur einmal initialisiert wird, nämlich vom BL, und damit ist die Instanz 
von SystemCoreClock von der Applikation undefiniert. Die Variable wird 
aber zuweilen benutzt, u.A. um Ableitungsfaktoren für Baudraten u.ä. zu 
berechnen).

Das sind zwei der Gründe, warum ich mit der HAL von ST nicht so 
begeistert bin; erstensmal benutzt sie von mir ungefragt einen 
Timerinterrupt für ein busy wait (dessen Priorität ich sowieso erst in 
mein Schema unterbringen muss, also ganz transparent ist es sowieso 
nicht, und vermutlich könnte ich applikationswaits besser durch 
suspended waits realisieren), und zweitens sind diese 
Bootloaderunverträglichkeiten sehr sehr gemeine Angelegenheiten zum 
Debuggen.

Ruediger A. schrieb:
> Wenn Du zwei komplett voneinander getrennte Instanzen von der HAL hast,
> können die nicht miteinander funktionieren, jedenfalls nicht solange Du
> die Standardimplementation benutzt.

Die funktionieren auch nicht miteinander, sondern nacheinander.

Ich mache das genauso wie Steffen, sowohl der Bootloader als auch die 
Applikation benutzen die HAL-Lib. Aber beide wissen nichts voneinander 
(außer die Startadresse der Application Vector Table und die CRC der 
Appl.). Deshalb kann man auch nicht von 2 verschiedenen Instanzen 
sprechen.

Gruß, Stefan

Stefan K. schrieb:
> Ruediger A. schrieb:
>> Wenn Du zwei komplett voneinander getrennte Instanzen von der HAL hast,
>> können die nicht miteinander funktionieren, jedenfalls nicht solange Du
>> die Standardimplementation benutzt.
>
> Die funktionieren auch nicht miteinander, sondern nacheinander.
>
> Ich mache das genauso wie Steffen, sowohl der Bootloader als auch die
> Applikation benutzen die HAL-Lib. Aber beide wissen nichts voneinander
> (außer die Startadresse der Application Vector Table und die CRC der
> Appl.). Deshalb kann man auch nicht von 2 verschiedenen Instanzen
> sprechen.
>

Also sind die BL nach Starten der App komplett inaktiv? Dann kann das 
funktionieren. In den BLs, die ich geschrieben habe, ist das aber nicht 
der Fall. Da hängt z.B. der BL mit im Hostkommunikationsprotokoll drin, 
filtert alle Softwaredownloadtelegramme heraus, baut das 
Applikationsimage aus den Telegrammen und flasht es dann. Da es vor 
Allem bei kleineren Controllern schwer möglich ist, so etwas potentiell 
footprintreiches wie Hostkommunikationscode zu verdoppeln, wird bei 
diesen Systemen kontrolliert zwischen BL und App hin- und her 
aufgerufen, und da werden solche Themen relevant.

Man kann auf die Art und Weise sogar mit 32k RAM und 128k Flash einen 
selbst und die Applikation upgradenden Bootloader mit minimalem eigenen 
footprint schreiben.

> Gruß, Stefan

Zurück ;-)

Ruediger A. schrieb:
> Hast Du zwei verschiedene Instanzen der HAL, dann hast Du auch zwei
> voneinander unbhängige Instanzen von uwTick - aber vermutlich nur einen
> ISR (HAL_InitTick() benutzt zumindestens in der Standardimplementation
> nur einen Timer).

2 Programme
2 Vektortabellen, daher ist das Umstellen so wichtig
2 unabhängige Interrupthandler

=> Da die Applikation nichts von Interrupthandler des Bootloaders weiß, 
kann sie diesen auch nicht nutzen. Der Preis der Unabhängigkeit.

Ruediger A. schrieb:
> denn die Prozessorfrequenz ist ebenfalls in einer
> globalen Variable abgelegt, nämlich SystemCoreClock

Den Prozessor interessiert diese Variable garnicht.
Aber davon abgesehen, wird diese von der clib des Bootloaders auf den 
Initialwert des Bootloaders gesetzt und von der clib der Applikation auf 
den Initialwert der Applikation.
Und natürlich kann diese Variable in jedem Fall an einer anderen Stelle 
liegen.

Ich glaube du hast eher deinen Punkt 1 im Blick, bei der die HAL nur 
einmal im Flash liegt. In dem Fall müssen alle Beteiligten die gleichen 
Adressen nutzen. Und dann wird es aus meiner Sicht kompliziert.

Ich finde meinen Weg einfacher, weil man an fast nichts denken muss und 
eine Applikation auch leicht ohne Bootloader testen kann. Aber natürlich 
verbraucht dies zusätzlichen Flash.

Ruediger A. schrieb:
> Da es vor
> Allem bei kleineren Controllern schwer möglich ist, so etwas potentiell
> footprintreiches wie Hostkommunikationscode zu verdoppeln, wird bei
> diesen Systemen kontrolliert zwischen BL und App hin- und her
> aufgerufen, und da werden solche Themen relevant.

Das verstehe ich, das ist natürlich ein ganz anderer Fall.
Bei uns ist glücklicherweise immer mehr als genug Flash übrig, so dass 
solche Klimmzüge nicht nötig werden.

Viele Grüße, Stefan

Ruediger A. schrieb:
> Man kann auf die Art und Weise sogar mit 32k RAM und 128k Flash

Wieviel Funktiionalität packt ihr in den Bootloader und wie komplex ist 
Eure Hostkommunikation, dass du einen 128k Flash Prozessor als klein 
bezeichnest?

Neugier ist ernst gemeint.

Steffen R. schrieb:
> Ruediger A. schrieb:
>> Man kann auf die Art und Weise sogar mit 32k RAM und 128k Flash
>
> Wieviel Funktiionalität packt ihr in den Bootloader und wie komplex ist
> Eure Hostkommunikation, dass du einen 128k Flash Prozessor als klein
> bezeichnest?
>
> Neugier ist ernst gemeint.

Hast ne PM