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.
:
Bearbeitet durch Moderator
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.