Hallo Miteinander, ich habe eine allgemeine Frage beim verschieben (Offset) vom User Code bei einem ARM Cortex M4. Ich hab einen Bootloader und dazu eine Windows Applikation erstellt, die mit dem Bootloader kommuniziert und die zu ladende Hex File überträgt. Das Übertragen und speichern scheint zu funktionieren, da der Speicher nachdem übertragen der Hex File, ausgelesen wurde und sich an der definierten Adresse dann Daten zu finden sind. Was nicht funktioniert ist das Springen zum User Code. Der Bootloader befindet sich am Anfang des Flash Speichers und der User Code am Anfang vom nächsten Sektor. Im Linker Script des User Codes wurde wurde ein Offset erstellt. MEMORY { FLASH_1_cached(RX) : ORIGIN = 0x08004000, LENGTH = 0x100000-0x4000 FLASH_1_uncached(RX) : ORIGIN = 0x0C004000, LENGTH = 0x100000-0x4000 PSRAM_1(!RX) : ORIGIN = 0x10000000, LENGTH = 0x10000 DSRAM_1_system(!RX) : ORIGIN = 0x20000000, LENGTH = 0x10000 DSRAM_2_comm(!RX) : ORIGIN = 0x30000000, LENGTH = 0x8000 } In der Map File befindet sich der Reset Handler an der Offset Adresse. Der Sprung vom Bootloader zum User Code funktioniert leider irgendwie nicht. void RunFlash(void) { __asm( "ldr r0, =0x0C004000\n" "ldr r1, =0xE000ED08\n" //VTOR register "str r0,[r1]\n" "ldr sp, [r0], #4\n" "ldr r15, [R0]" ); } Bin recht neu in der ARM Welt unterwegs. Hat vielleicht jemand einen Tipp für mich?
Gast
#4507584
Bubba L. schrieb: > Der Bootloader befindet sich am Anfang des Flash Speichers und der User > Code am Anfang vom nächsten Sektor Zur Info: die meisten ARM ausser XMC z.B. LPC, STM32 haben einen ROM (oder Flash Security Page) Bootloader. Das ROM wird als High Memory eingeblendet. Der User Code beginnt also unabhängig davon, ob ein Bootloader existiert oder nicht, bei 0 und beinhaltet die Vektortabelle. Somit müssen nicht verschiedene HEX gelinkt werden. Zum Starten des User Code aus einem Bootloader, der selbst nach der Vektortabelle beginnt, wird am einfachsten ein Software-Reset ausgelöst mit NVIC_SystemReset()
Gast
#4507587
Da schau ich mal ins Manual: On system reset, the vector table is fixed at address 0x00000000. Privileged software can write to the VTOR to relocate the vect or table start address to a different memory location, in the range 0x00000400 to 0x3FFF FC00
Bubba L. schrieb: > Hat vielleicht jemand einen Tipp für mich? Debugger ranhängen und uns mitteilen wo genau er aussteigt. Was gerne vergessen wird ist das T-Bit bei Vectoradressen, dann würde "LDR PC, [R0]" in einem Hardfault enden.
Lothar schrieb: > Bubba L. schrieb: >> Der Bootloader befindet sich am Anfang des Flash Speichers und der User >> Code am Anfang vom nächsten Sektor > > Zur Info: die meisten ARM ausser XMC z.B. LPC, STM32 haben einen ROM > (oder Flash Security Page) Bootloader. Das ROM wird als High Memory > eingeblendet. Der User Code beginnt also unabhängig davon, ob ein > Bootloader existiert oder nicht, bei 0 und beinhaltet die Vektortabelle. > Somit müssen nicht verschiedene HEX gelinkt werden. > > Zum Starten des User Code aus einem Bootloader, der selbst nach der > Vektortabelle beginnt, wird am einfachsten ein Software-Reset ausgelöst > mit NVIC_SystemReset() Nach der Vektortabelle beginnt zuerst der Bootloader. Er wartet 3 Sekunden auf ein Befehl die UART Schnittstelle. Wenn kein Befehl erhalten wird, dann soll er zum User Code an der Adresse (0x0C004000) springen. boot @ 0000 0000 h schrieb: > Da schau ich mal ins Manual: > On system reset, the vector table is fixed at address 0x00000000. > Privileged software > can write to the VTOR to relocate the vect > or table start address to a different memory > location, in the range 0x00000400 to 0x3FFF > FC00 Das habe ich auch gelesen, aber weiß nicht wie ich den privileged modus starte oder ob dieser automatisch bei einem bestimmten Befehl kurz aktiviert wird? Ich habe den Offset mit diesen beiden Befehlen versucht. PPB->VTOR = 0x0C004000; SCB->VTOR = 0x0C004000; Jim M. schrieb: > Bubba L. schrieb: >> Hat vielleicht jemand einen Tipp für mich? > > Debugger ranhängen und uns mitteilen wo genau er aussteigt. > > Was gerne vergessen wird ist das T-Bit bei Vectoradressen, dann würde > "LDR PC, [R0]" in einem Hardfault enden. Er steigt an der Adresse 0x080042B0 aus mit der Meldung " No source available for "0x80042b0" ". 0x08004000 ist identisch zu 0x0C00400. Beim auslesen des Flash sind an den Adressen aufwärts die Daten identisch. Was ist ein T-Bit? Wiki hat mich nicht schlauer gemacht (https://de.wikipedia.org/wiki/Sticky_Bit). Den Sprung befehl habe ich aus dem Bootloader Beispiel von Infenion entnommen.
Hier ein Screenshot der beiden Adressen vom Flash
Angehängte Dateien:
-
FLASH.JPG
(74 KB)
-
FLASH2.JPG
(70 KB)
Hier ein ein Screenshot vom Disassembly während dem Debuggen. Hier scheint es so als ob an der Adresse 0x0C004000 keine Befehle vorhanden sind? Er gelangt aber trotzden bis zur Adresse 0x080042B0 bevor die Meldung "No source available for "0x80042b0" ausgegeben wird.
Angehängte Dateien:
-
DebuggenFLASH.JPG
(48 KB)
Bubba L. schrieb: > Er steigt an der Adresse 0x080042B0 aus mit der Meldung > > " No source available for "0x80042b0" ". Das ist dann wohl ein Fault, denn im anderen Posting sieht man dass das die Default Handler Addresse ist. Und zwar die von der Applikation. Ich definiere mir immer einen eigenen Handler dafür, dann sieht man Fehler besser. Für die Source müsstest Du jetzt die Symbole der Applikation nachladen, der Default Handler ist aber oft in einem Assembler File deklariert. Bubba L. schrieb: > Was ist ein T-Bit? Das unterste Bit der Addresse, bei Dir überall korrekt gesetzt. Schaltet bei ARM zwischen ARM- und Thumb Instruktionen um. Was Du überprüfen solltest sind die Linker Flags der Applikation. Wenn die flachsen Libs verlinkt wurden wäre das eine Ursache für einen Fault, man mus auch dem Linker den CPU Typ mitgeben.
Jim M. schrieb: > Das ist dann wohl ein Fault, denn im anderen Posting sieht man dass das > die Default Handler Addresse ist. Und zwar die von der Applikation. > Ich definiere mir immer einen eigenen Handler dafür, dann sieht man > Fehler besser. Blöde Frage...wie definiert man den am Besten? Hast du da ein Beispiel? in der startup.S Datei ist folgendes bereits drin
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
78 | |
79 | |
80 | |
81 | |
82 | |
83 | |
84 | |
85 | |
86 | |
87 | |
88 | |
89 | |
90 | |
91 | |
92 | |
93 | |
94 | |
95 | |
96 | |
97 | |
98 | |
99 | |
100 | |
101 | |
102 | |
103 | |
104 | |
105 | |
106 | |
107 | |
108 | |
109 | |
110 | |
111 | |
112 | |
113 | |
114 | |
115 | |
116 | |
117 | |
118 | |
119 | |
120 | |
121 | |
122 | |
123 | |
124 | |
125 | |
126 | |
127 | |
Jim M. schrieb: > Für die Source müsstest Du jetzt die Symbole der Applikation nachladen, > der > Default Handler ist aber oft in einem Assembler File deklariert. Nachladen? Wie genau? Die müssten doch bereits im Flash liegen, oder? Jim M. schrieb: > Was Du überprüfen solltest sind die Linker Flags der Applikation. Wenn > die flachsen Libs verlinkt wurden wäre das eine Ursache für einen Fault, > man mus auch dem Linker den CPU Typ mitgeben. Das müsste doch im linker script stehen oder? Finde da nichts :(
Gast
#4509490
Hallo,
vom Prinzip ist dein Linkerscript schon richtig.
Bei mir liegt der Bootloader in den ersten 64K. Und die Applikation ab
0x8080000.
Wenn ich aus dem Bootloader die Applikation starten möchte, dann biege
ich den internen Bootloader auf den "Alternative Boot mode" um (Siehe
Kapitel: 26 "Startup modes" im Reference Manual)
Hier ein Beispiel wie ich es mache:
Zuvor noch den Sektor für "flash_abm0" im Linkerscript definieren usw.
Wenn du eine andere Startadresse benutzt, dann entsprechend die CRC32
neu berechnen.
static const ABM_Header_t __attribute__((section(".flash_abm0")))
ABM0_Header=
{
// 0x5AC3E10F (RM : Kap 26.2.5)
.MagicKey = MAGIC_KEY,
// Adresse ab der die Applikation liegt
.StartAddress = 0x08080000,
.Length = 0xFFFFFFFF,
.ApplicationCRC32 = 0xFFFFFFFF,
.HeaderCRC32 = 0xCBF94C7D
};
void StartApplication(void)
{
SCU_RESET->RSTCLR = 1<<SCU_RESET_RSTCLR_RSCLR_Pos;
WR_REG( SCU_GENERAL->STCON,
SCU_GENERAL_STCON_SWCON_Msk,
SCU_GENERAL_STCON_SWCON_Pos,
SW_CONFIG_ABM0);
PPB->AIRCR = (1 << PPB_AIRCR_SYSRESETREQ_Pos)
| (0x5FA<<PPB_AIRCR_VECTKEY_Pos)
| (0x1 << PPB_AIRCR_PRIGROUP_Pos);
}
Gruss Markus
Markus S schrieb: > Wenn ich aus dem Bootloader die Applikation starten möchte, dann biege > ich den internen Bootloader auf den "Alternative Boot mode" um (Siehe > Kapitel: 26 "Startup modes" im Reference Manual) Ich habe auch mit dem Gedanken gespielt, es mit dem ABM Modus zu versuchen, aber habe es doch nicht probiert :( Markus S schrieb: > Hier ein Beispiel wie ich es mache: > Zuvor noch den Sektor für "flash_abm0" im Linkerscript definieren usw. Der Sektor für "flash_abm0" ist laut Reference Manual die letzten 32 Bytes des PSRAMS. also von 0xFFFFFFF00 bis zum Ende. Ich werde es dann so definieren.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
Du hast den ABM aber im flash wie ich sehe?? Markus S schrieb: > Wenn du eine andere Startadresse benutzt, dann entsprechend die CRC32 > neu berechnen. Zur CRC Berechnung werde ich mal den Code ausm Infenion Forum verwenden... [http://www.infineonforums.com/threads/2114-Crc32?p=6561&viewfull=1#post6561] Ein System Reset hast du ja nicht gebraucht,oder? Danke für die Tipps. Werde es morgen früh mal testen.
Hallo zusammen, bin erst heute wieder dazu gekommen an dem Bootloader weiter zu arbeiten. Aktueller Status: Ich habe mir jetzt den ABM Header erstellt. Eine Frage zu den CRC Prüfsummen. Diese müssen ja auf den "leeren" Speicherbereich angewendet werden, also wenn noch keine Applikation über den Bootloader geladen wurde? Der Header wird einmal an die Adresse 0x0C00FFE0 geflasht und gut is. Jedoch wenn ich den internen Bootloader auf den Alternate Boot Mode umbiege, dann läuft was schief und der Mikrocontroller reagiert nicht, auch nicht auf einen system reset. Nach einem PORST ist dann wieder alles normal bis der interne Bootloader wieder auf den ABM Mode gebogen wird. Ich nehme an dass der diagnostics monitor mode gestartet (RM: Kap 26.2.6) wird weil der Stromverbauch sinkt, nachdem auf ABM gestellt wurde und ein system reset erfolgt. Der Header ist vermutlich corrputed. Für die Berechnung habe ich folgende Funktionen (aus einem ABM Beispielcode von Infenion) verwendet
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
Die Size der Applikation wurde mit folgenden Parametern berechnet.
1 | |
2 | |
und ABM Header habe ich berechnet mit
1 | |
2 | |
Mein Fehler liegt womöglich daran dass ich bei Berechnen der crc nicht einen pointer auf die Daten übergeben habe. Im Beispiel wurde die start adresse wie folgt berechnet
1 | |
Werde es morgen nochmal probieren. @Markus S Nach der Funktion StartApplication() muss ein SystemReset erfolgen, oder?
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
Habe es hinbekommen. Danke für eure Hilfe.
Gast
#4534354
Ein Nachtrag: Lothar schrieb: > Zur Info: die meisten ARM ausser XMC z.B. LPC, STM32 haben einen ROM > (oder Flash Security Page) Bootloader. Das ROM wird als High Memory > eingeblendet. Der User Code beginnt also unabhängig davon, ob ein > Bootloader existiert oder nicht, bei 0 und beinhaltet die Vektortabelle. > Somit müssen nicht verschiedene HEX gelinkt werden. Tja. Diese XMC sind eben genau deshalb auf meiner privaten schwarzen Liste. Bei den M4 Varianten könnte man ja (vermutlichst) die Vektortabelle umverlegen, aber bei den M0 und M0+ geht das nicht, also ist man auf deren von DAVE generierten Krempel angewiesen - und das ist mir so unangenehm wie ne Kette am Nasenring und damit bei Infineon angeschmiedet. W.S.
W.S. schrieb: > aber bei den M0 und M0+ geht das nicht Bei allen Cortexen ab (inclusive) M0+ aufwärts kann man die Vektortabelle verlegen. Das ist ein Feature von ARM, nicht des Herstellers. Nur bei M0 bin ich mir nicht sicher ob das da auch geht.
Gast
#4735763
Hallo, das mit der CRC Berechnung für den ABM funktioniert bei mir ebenfalls nicht. Welche CRC Funktion müsste ich dazu verwenden? Welche Übergabeparamter muss ich der CRC Funktion geben?
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.