ATSAMD09C13A allgemeines

[Alex Richard Moll (Gast)]

Servus,

ich habe Paar Fragen zu ARM auf die ich bisher keine Lösung gefunden 
habe.

1, rein zum Testen möchte ich Instruktionen aus dem RAM ausführen. Hier 
hat jemand danach schon mal gefragt: 
Beitrag "ATSAMD09C13A externe Opcodes?" allerdings gibt es die 
AppNote nicht mehr aus dem Letzen Post.

Habe mir zum Testen einfach mal den Opcode in eine Statische Variable 
gelegt und mir anhand eines Pointers die Speicheradresse geben lassen. 
Mit "mov PC, %0:+r(address) springe ich dann Dort hin. Das einzige was 
passiert ist das die Hardfault ISR aufgerufen wird. Der Opcode 
allerdings nicht. Ich denke ich gehe das Falsch an, wie mache ich es 
richtig?
Hänge mal meinen Code mit an, habe die Adresse zum Ausprobieren auch mal 
manuell eingestellt. Habe gelesen das der Hardfault ausgelöst wird wenn 
die Adresse gerade ist?

2, wenn ich mir den PC auslese, wird die Adresse vier Bytes in der 
"Zukunft" angezeigt. Das heißt der Instruction-fetch holt zwei weitere 
Instruktionen während der Abfrage von z.b. "mov %0, PC". Liege ich da 
richtig?

3, bei AVR gibt es ein sehr schönes Handbuch über die Instruktionen mit 
Aufbau und sehr genauen Erklärungen. Bei ARM habe ich zwar Erklärungen 
gefunden aber nicht die genaue Zusammensetzung über die Instruktionen, 
ebenfalls von den Thumb Instruktionen. Gibt es da was und ich habe es 
einfach nur übersehen?

BG
Alex

[Jörg W. (dl8dtl) (Moderator)]

Alex Richard Moll schrieb:

> 1, rein zum Testen möchte ich Instruktionen aus dem RAM ausführen.

Dafür musst du erstmal den Code auf die entsprechenden Adressen linken. 
Normaler ARM-Code ist nicht verschieblich, d.h. er läuft nur auf den 
Adressen, für die er compiliert und gelinkt worden ist.

Dann muss der Startup-Code sie (wie die Inhalte der initialisierten 
Variablen) aus dem Flash an die passende Stelle im RAM ablegen. 
Inwiefern da Linkerscripte und Startup-Code schon Vorkehrungen haben, 
habe ich noch nicht geguckt – dummerweise kommt ja bei ARM jedes System 
(IDE etc.) oft mit eigenen Varianten dieser beiden Teile daher. Wenn das 
getan ist, kannst du sie ganz normal mit Namen aufrufen.

> Habe mir zum Testen einfach mal den Opcode in eine Statische Variable
> gelegt und mir anhand eines Pointers die Speicheradresse geben lassen.
> Mit "mov PC, %0:+r(address) springe ich dann Dort hin. Das einzige was
> passiert ist das die Hardfault ISR aufgerufen wird.

Da du dann auf eine gerade Adresse springst, versuchst du, den 
Thumb-Modus zu verlassen, was bei einem Cortex-M schlicht nicht geht. 
Der kann nur Thumb-Modus.

> Liege ich da
> richtig?

Könnte schon sein.

> Gibt es da was und ich habe es
> einfach nur übersehen?

Ich denke, dass es sowas auch bei ARM gibt, aber viele Dinge behandeln 
sie dort als proprietär. Man muss sich dann anmelden und darf die 
Dokumente auch nicht weitergeben.

[Alex Richard Moll (Gast)]

Jörg W. schrieb:
> Dafür musst du erstmal den Code auf die entsprechenden Adressen linken.
> Normaler ARM-Code ist nicht verschieblich, d.h. er läuft nur auf den
> Adressen, für die er compiliert und gelinkt worden ist.

Gut das ist klar. Ein Befehl der aber nur eine LED umschaltet, hat in 
dem Sinn ja keine Adresse die gelinkt werden muss?

Jörg W. schrieb:
> Dann muss der Startup-Code sie (wie die Inhalte der initialisierten
> Variablen) aus dem Flash an die passende Stelle im RAM ablegen.

Gibt es da irgendwo eine Anleitung? Die Datenblätter geben da nichts 
her.

Jörg W. schrieb:
> Da du dann auf eine gerade Adresse springst, versuchst du, den
> Thumb-Modus zu verlassen, was bei einem Cortex-M schlicht nicht geht.
> Der kann nur Thumb-Modus.

Bei einer ungeraden Adresse passiert das gleiche

Jörg W. schrieb:
> Ich denke, dass es sowas auch bei ARM gibt, aber viele Dinge behandeln
> sie dort als proprietär. Man muss sich dann anmelden und darf die
> Dokumente auch nicht weitergeben.

Hab ich mal gemacht, aber nicht unbedingt fündiger geworden.

Danke dir (:

[Alex Richard Moll (Gast)]

Ich habe eine Frage vergessen, der Flash eines AVR leer ist, läuft der 
PC ja immer wieder durch. Kann es sein das bei ARM der PC bei der 
letzten Adresse stehen bleibt und neu gestartet werden muss? Hab da mal 
beim debuggen was gesehen.

[Frank K. (fchk)]

Alex Richard Moll schrieb:

> 1, rein zum Testen möchte ich Instruktionen aus dem RAM ausführen.

https://ez.analog.com/dsp/software-and-development-tools/linux-blackfin/f/q-a/68624/run-a-specific-function-from-sram-gnu-gcc-compilation-tools

fchk

[Jörg W. (dl8dtl) (Moderator)]

Alex Richard Moll schrieb:

> Jörg W. schrieb:
>> Dann muss der Startup-Code sie (wie die Inhalte der initialisierten
>> Variablen) aus dem Flash an die passende Stelle im RAM ablegen.
>
> Gibt es da irgendwo eine Anleitung? Die Datenblätter geben da nichts
> her.

Das hat ja auch nichts mit dem Datenblatt zu tun.

Du müsstest dich hinsetzen und verstehen, was der Startup-Code tut und 
wie er mit dem Linkerscript zusammen spielt. "Kochrezepte" sind das eine 
(kenne ich gerade keins), Verständnis das andere: damit kann man sich 
sowas auch selbst erweitern, wenn noch nicht vorhanden.

Als erstes müsstest du aber sehen, was in deiner Build-Umgebung 
überhaupt da ist in dieser Richtung. Wie gesagt, anders als bei AVR, wo 
die Toolchain im Großen und Ganzen Linkerscripte und Startup-Code "aus 
einer Hand" geliefert hat, kocht bei ARM jeder (jeder Hersteller, jede 
IDE) sein eigenes Süppchen in dieser Hinsicht.

Alex Richard Moll schrieb:
> Kann es sein das bei ARM der PC bei der letzten Adresse stehen bleibt
> und neu gestartet werden muss?

Ich würde vermuten, dass er beim Erreichen eines 0xFFFFFFFF sofort einen 
Hardfault triggert, da das kein gültiger Befehl ist. Beim AVR war 0xFFFF 
einfach ein (undokumentierter) NOP, weshalb der PC immer wieder durch 
lief.