STM32F4 + OpenBLT (Bootloader) + emWin Probleme

[MM2forever (Gast)]

Hallo Forum,

Seit geraumer Zeit kämpfe ich nun mit dem folgenden Problem:

Ich habe die Konstellation das ich auf einem STM32F4 Controller ein 
emWin von Segger laufen habe. Das funktioniert soweit gut, doch wenn ich 
OpenBLT, einen 2nd-Level Bootloader aufspiele und dann per SD-Karte die 
vorher Funktionsfähige Anwendung aufspiele bleibt diese beim GUI_Init 
von emWin hängen.

Ich habe diese Frage schon in anderen Foren gepostet, ohne Erfolg.

http://forum.segger.com/index.php?page=Thread&threadID=2204

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fSTemWin%20-%20GUI_Init%28%29%20hangs%20after%20use%20of%20a%202nd%20Level%20Bootloader%20on%20STM32F429&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&TopicsView=https%3A%2F%2Fmy.st.com%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FAllItems.aspx&currentviews=0

Ich hoffe es findet sich jemand der den entscheidenden Tipp geben kann.

Soweit habe ich alles beachtet wie z.b. deaktivieren und aktivieren der 
Interrupts vor/nach dem verschieben der Vektortabelle.

Wer mehr wissen möchte bitte fragen,
ich bin für jede Hilfe sehr Dankbar!

Gruss
MM2forever

[alibaba (Gast)]

Da wird wohl nur helfen einen Debugger dran zu hängen und zu schauen, 
warum es hängt. Mit nem Bootloader dazwischen ist es nicht mehr ganz so 
einfach zu debuggen, geht aber auch, wenn man etwas Zeit investiert. Man 
kann zB gdb sagen, dass es neben dem normalen image (in deinem Fall der 
Bootloader) noch andere Binaries gibt, deren Code an einer bestimmten 
Stelle im Speicher liegen (wo ihn der bootloader hingeschaufelt hat).

Folgendes zB in das gdbinit file eintragen um gdb mitzuteilen, dass 
foo.elf an position 0x12345678 geladen wurde:
add-symbol-file foo.elf 0x12345678

Viel Erfolg

[gnuopfer (Gast)]

Hi,

Es gibt einen Absturzgrund bei der emWin-lib der gerne übersehen wird:
Aller Speicher der an die lib übergeben wird, muss zuvor von Hand auf 0 
gesetzt werden, auch das Videoram !
Möglw. ist durch den Bootloader der statische Speicher beim 
Applikationsstart jetzt nicht mehr auf 0.

mfg

[MM2forever (Gast)]

Danke gnuopfer,

Das ist ein sehr guter Anstoss,
Leider funktioniert meine Umsetzung anscheinend noch nicht richtig...

Ich habe versucht das Array mit ={0}
und mit memset zu nullen, aber es funktioniert immer noch nicht.

Was mache ich falsch?

Gruss
MM2forever

[MM2forever (Gast)]

UPDATE:

Durch verschiedene Anpassungen am Linkerscript des User-Programms war es 
jetzt möglich einen Schritt weiter zu kommen.

Die Gui_X_Init Routine wird jetzt erfolgreich durchschritten.

Ich hatte noch vergessen zu erwähnen das auf dem Controller FreeRTOS 
läuft.
Wenn ich einen Test-Task erstelle in dem emwin geladen wird und ein 
einfacher String auf dem Display ausgegeben wird so funktioniert es.

Starte ich den original-Task aus dem Programm ohne Bootloader scheint 
der Controller jetzt sofort in den HardFault zu gehen.

Dieser Task der sonst ohne Bootloader Funktioniert ruft 
Initialisationsroutinen auf und erstellt weitere Tasks.

Kann es sein das es nach Verwendung des Bootloaders Probleme beim 
Context-Switching o.Ä. bzw. mit dem Priviliged Mode auftreten?

Ich bin mir auch noch nicht sicher ob das Linkerscript die richtigen 
Plätze
für Stack und co. einrichtet...

Danke,
MM2forever

[Tomas K. (Firma: tktronic) (tktronic)]

...benutzt Du die emWin-lib für ST ?

Wenn ja, schau mal ob das CRC-Peripheral in Deiner Applikation aktiv 
ist, das wird von der lib beim init abgefragt um zu sehen das es auf 
einem STM-uC läuft.

gruss, tom.