Servus,
wenn man beim AVR an die Adresse 0 springt, bewirkt es ja sowas wie
einen "Warmstart".
Mache ich das bei meinem Cortex M0+ wird entweder der Harfault ausgelöst
oder (laut debugger) an die Adresse 0xFFFFFFFF gesprungen. An der
Adresse 0 stehen ja nur Adressen und Werte aus der Vector Table, demnach
sind es keine Instruktionen das erklärt den Hardfault aber wieso wird
der Code nach einem Reset richtig ausgeführt?
Ich frage daher weil mein APPCode (mit Vector Table) an der Adresse
0x00000800 beginnt, springe ich dahin (vom Bootloader), erhalte ich
selbigen Fehler wie oben beschrieben. Ich müsste jedes mal auf die
main() (z.b. 0x000009C0) Funktion springen damit der Code richtig
ausgeführt wird. Da sich diese Adresse aber ändern kann wäre es
natürlich leichter direkt auf die Vector Table der APP aus dem
Bootloader zu springen.
Ich habe noch eine Frage, im Netz liest man von einem "Configurable
Fault Status Registers (CFSR) - 0xE000ED28". Mit dem man den Harfault
Fehler bestimmen kann, gibt es sowas für den Cortex M0+ auch? In den
Header Dateien ist zumindest für meinen Controller nichts zu finden in
Atmel Studio 7.
LG
Alex
Alex Richard Moll schrieb:> wenn man beim AVR an die Adresse 0 springt, bewirkt es ja sowas wie> einen "Warmstart".
Weil da der Resetvektor steht, und zwar als ausführbarer Code.
> Mache ich das bei meinem Cortex M0+ wird entweder der Harfault ausgelöst> oder (laut debugger) an die Adresse 0xFFFFFFFF gesprungen. An der> Adresse 0 stehen ja nur Adressen und Werte aus der Vector Table, demnach> sind es keine Instruktionen
Richtig – wobei niemand vorschreibt, dass er überhaupt auf Adresse 0
seine Vektortabelle suchen muss. Kann auch ab 0x400000 oder ganz
woanders sein. (Bei anderen Cortex-M ARMs.)
Außerdem steht auf dem ersten Platz der Tabelle der Ladewert für den
Stackpointer, der Zeiger auf die Reset-Routine steht erst auf dem
zweiten.
> das erklärt den Hardfault aber wieso wird> der Code nach einem Reset richtig ausgeführt?
Weil die Cortex-M-Architektur halt genau so definiert ist – und eben
anders als die AVR-Architektur.
> Ich frage daher weil mein APPCode (mit Vector Table) an der Adresse> 0x00000800 beginnt, springe ich dahin (vom Bootloader), erhalte ich> selbigen Fehler wie oben beschrieben. Ich müsste jedes mal auf die> main() (z.b. 0x000009C0) Funktion springen damit der Code richtig> ausgeführt wird. Da sich diese Adresse aber ändern kann wäre es> natürlich leichter direkt auf die Vector Table der APP aus dem> Bootloader zu springen.
Du musst dir den Inhalt von vectortable[1] laden und dahin springen.
> Ich habe noch eine Frage, im Netz liest man von einem "Configurable> Fault Status Registers (CFSR) - 0xE000ED28". Mit dem man den Harfault> Fehler bestimmen kann, gibt es sowas für den Cortex M0+ auch?
Der M0+ hat einige Sachen weniger als die größeren Cortex-M, u.d. gibt
es in diesem Bereich manche Dinge nicht. Details müsste ich aber auch
nachlesen, hatte ich mir mal angesehen.
Der SAMD21 hat einen Micro Trace Buffer, damit kann man die "History"
der Befehle aufzeichnen und später ansehen. Weiß nicht, ob der SAMD09
sowas auch hat.
Jörg W. schrieb:> Weil da der Resetvektor steht, und zwar als ausführbarer Code.
Manchmal hast du ne sehr eigenwillige Ausdrucksweise.
Also, beim Arm-Cortex steht ab Adresse 0 kein Code, sondern die
Vektortafel. Das sind (für begriffsstutzige C Programmierer) eine Reihe
von Pointern. Es ist kein Maschinen-Code.
Die ersten 2 Vektoren sind für den Stackpointer und den
Instructionpointer reserviert und die weiteren Vektoren sind für die
diversen Interrupt-Handler, wozu auch die Hard-Fault- und andere für die
CPU und deren Ausnahmen gehörigen Handler zählen.
Wenn man also den µC erneut starten will, dann lädt man den SP mit dem,
was in Vektor 0 drinsteht und dann springt man zu der Adresse, die in
Vektor 1 drinsteht. Das ist der Kaltstart-Handler.
Leute, bevor jemand vom AVR kommend meint, bei einem ARM ginge alles
genauso wie er es beim AVR gewohnt ist, sollte dieser Jemand lieber mal
die Nase ins Buch stecken und nachlesen. Immer mal dran denken, daß auch
beim 8086 und seinen Nachfolgern der Kaltstart nicht stur ab Adresse 0
beginnt und auch bei den µC ist das recht unterschiedlich.
W.S.
Jörg W. schrieb:> Du musst dir den Inhalt von vectortable[1] laden und dahin springen.
Stimmt, damit funktioniert es. Danke!
Jörg W. schrieb:> Der M0+ hat einige Sachen weniger als die größeren Cortex-M, u.d. gibt> es in diesem Bereich manche Dinge nicht. Details müsste ich aber auch> nachlesen, hatte ich mir mal angesehen.>> Der SAMD21 hat einen Micro Trace Buffer, damit kann man die "History"> der Befehle aufzeichnen und später ansehen. Weiß nicht, ob der SAMD09> sowas auch hat.
Dann denke ich eher das beides nicht vorhanden ist, wird beim Cortex M0+
Datenblatt auch nicht aufgeführt leider.
Danke für deine Ausführliche Erklärung und Zeit!
LG
Alex
W.S. schrieb:> Leute, bevor jemand vom AVR kommend meint, bei einem ARM ginge alles> genauso wie er es beim AVR gewohnt ist, sollte dieser Jemand lieber mal> die Nase ins Buch stecken und nachlesen. Immer mal dran denken, daß auch> beim 8086 und seinen Nachfolgern der Kaltstart nicht stur ab Adresse 0> beginnt und auch bei den µC ist das recht unterschiedlich.
Damit wollte ich dich auf jeden Fall nicht angreifen, mir ging es
eigentlich rein darum eine bessere Erklärung meines (ehemaligen)
Problems zu schildern.
Danke aber auch für deine Erklärung!
LG
Alex
Alex Richard Moll schrieb:> Damit wollte ich dich auf jeden Fall nicht angreifen,
Hab das auch nicht so aufgefaßt. Aber Jörgs Antwortzeile, die ich
zitiert hab, ist schon ein wenig eigentümlich formuliert.
Aber mal aus Interesse: Wieso willst du so etwas wie das erneute
Durchlaufen des Kaltstartcodes überhaupt?
W.S.
Alex Richard Moll schrieb:>> Der SAMD21 hat einen Micro Trace Buffer, damit kann man die "History">> der Befehle aufzeichnen und später ansehen. Weiß nicht, ob der SAMD09>> sowas auch hat.>> Dann denke ich eher das beides nicht vorhanden ist, wird beim Cortex M0+> Datenblatt auch nicht aufgeführt leider.
Der SAMD21 ist auch ein M0+.
W.S. schrieb:> Wieso willst du so etwas wie das erneute Durchlaufen des Kaltstartcodes> überhaupt?
Wie springst du sonst vom Bootloader in die Applikation? (Das Wort
"Bootloader" stand im Originalposting.)
Bootloader waren beim AVR in der Tat m.E. eleganter gelöst, denn dort
konnte man die eigentliche Applikation mit oder ohne Bootloader
gleichermaßen benutzen. Bei den Cortex-M dagegen springt man immer
erstmal auf die gleiche Vektortabelle, und wenn man einen Bootloader
benutzen will, muss man den dahin packen. Die Applikation muss man dann
auf eine höhere Adresse linken, und dann die Vektortabelle dahin
umbiegen.
Jörg W. schrieb:> Bootloader waren beim AVR in der Tat m.E. eleganter gelöst, denn dort> konnte man die eigentliche Applikation mit oder ohne Bootloader> gleichermaßen benutzen.
Außer bei den Attinys (z.B. Attiny2313), dort muss man es genauso lösen.
Jörg W. schrieb:> Der SAMD21 ist auch ein M0+.
Stimmt, dann schau ich nochmal nach..
LG
Alex
W.S. schrieb:> Jörg W. schrieb:>> Weil da der Resetvektor steht, und zwar als ausführbarer Code.>> Manchmal hast du ne sehr eigenwillige Ausdrucksweise.
Und du hast eine sehr eigenwillige Art, zu zitieren.
> Also, beim Arm-Cortex steht ab Adresse 0 kein Code, sondern die> Vektortafel. Das sind (für begriffsstutzige C Programmierer) eine> Reihe von Pointern. Es ist kein Maschinen-Code.
Ja. Aber nicht beim AVR. Genau darauf bezog sich Jörg aber.
Beim AVR heißt das Ding zwar auch "Vektortabelle". Aber es ist
eigentlich eine Sprungtabelle. Und enthält ausführbaren Code.
