arm-glue- mit arm-none-eabi-: target CPU does not support ARM mode

[Geri (Gast)]

Hallo zusammen


Ich habe gerade versucht ein Mini-Led-Blink-Beispiel für den LPC1768 mit 
arm-none-eabi-gcc im uVision-Editor zu compilieren. Ich verwende dazu 
die "glue-Dateien" von Martin Thomas.

Wenn ich aus der Kommandozeile mit einem makefile compiliere, dann lässt 
sich das Programm einwandfrei compilieren.


Wenn ich mit dem Glue:) im uVision-Editor compiliere, dann erhalte ich 
die Fehlermeldung:

compiling system_LPC17xx.c...
system_LPC17xx.c(1): error: target CPU does not support ARM mode
compiling core_cm3.c...
core_cm3.c(1): error: target CPU does not support ARM mode
compiling main.c...
main.c(1): error: target CPU does not support ARM mode
compiling startup_LPC17xx.c...
startup_LPC17xx.c(1): error: target CPU does not support ARM mode

Ich nehme an, es liegt an den Compiler-Flags
Momentan compiliere ich mit:

-c -mcpu=cortex-m3 -gdwarf-2 -MD -Wall -O -mapcs-frame -mthumb-interwork -IC:\Programs\yagarto\INC\NXP\LPC17xx\ -o *.o

Soweit ich gelesen und verstanden habe, sind darin die wesentlichen 
Schlüsselwörter enthalten.

Ich habe natürlich schon gegoogelt, komme aber nicht so richtig weiter. 
Habt ihr vielleicht eine Idee woran es liegt?

Vielen Dank für eure Tipps

Geri

[(prx) A. K. (prx)]

Stolpert man gern drüber, denn -mcpu=cortex-m3 allein reicht nicht.
Nötig ist zusätzlich -mthumb.

[Geri (Gast)]

Hallo Andreas

Vielen Dank für deinen Hinweis! Ich habe es versucht, das Ergebnis ist 
allerdings noch das Gleiche.

Beste Grüsse

Geri

[(prx) A. K. (prx)]

Ach ja, lass das Interworking weg. Ergibt bei einem Cortex M keinerlei 
Sinn.

[Geri (Gast)]

Hallo Andreas

Vielen Dank, nun klappt es. Das Problem lag - wie du sagtest - daran, 
dass kein thumb-Code erzeugt wurde weil die Checkbox thumb nicht 
aktiviert war und der Compiler mthumb dann anscheinend ignoriert bzw. 
die erste Definition höhere Priorität hat.

Beste Grüsse

Geri

[Geri (Gast)]

Gerade ist mir noch eingefallen..

Ob man uVision auch noch dazu bringen kann den erzeugten Code zu 
debuggen oder zumindest zu simulieren?

Bei WINARM funktioniert das ja super. Irgendwie muss der Code aber wohl 
beschaffen sein, dass das geht.

Beste Grüsse und Danke für eure Tipps

Geri

[Martin T. (mthomas) (Moderator)]

Das "arm-glue"-Packet braucht man eigentlich nicht mehr. Habe es schon 
länger nicht mehr ausprobiert aber neuere Versionen von uVision haben 
beim letzten Test die Komandozeilenparameter für die GNU-Toolchain 
korrekt übergeben, so dass kein "zurechtbiegen" (nichts anderes machen 
die "arm-glue"-Progrämmchen) mehr nötig war.

Beim letzten Mal ausprobieren konnte der uVision Simulator/Debugger auch 
mit von GNU Tools erzeugem Code (elf-Datei, arm-eabi Format) umgehen. 
Gibte es Fehlermeldungen beim Start des Simulators? Kann man zumindest 
duch das Disassembly durchsteppen? Ansonsten wohl eher ein Fall für den 
Keil Support und/oder das Forum auf keil.com.

[Geri (Gast)]

Hallo Martin

Vielen Dank für deine Hilfe. Vielen Dank auch für die 
Zurverfügungstellung des WINARM-Paketes mit den vielen top Beispielen! 
Habe einiges daraus gelernt.

Bzgl.Debugging: Ich erhalte keinen Fehler, dort wo man aber 
normalerweise Haltepunkte setzen kann (grauefarbene Rechtecke) sind 
entweder keine oder sie sind irgendwo verstreut. Ein elf-File wird 
erzeugt. Vielleicht liegt es aber gar beim Code. Habe bereits ein paar 
Beispiel von verschiedenen Webseiten probiert.

Anbei das Beispiel. Ist sogar Quellcode von dir dabei:)

Bei Keil ist man bestimmt wenig daran interessiert, dass gcc in uVision 
funktioniert. Habe aber dort schon nachgeschaut.

Beste Grüsse und vielen Dank nochmals

Geri

[Martin T. (mthomas) (Moderator)]

Geri schrieb:
> Hallo Martin
>
> Vielen Dank für deine Hilfe. Vielen Dank auch für die
> Zurverfügungstellung des WINARM-Paketes mit den vielen top Beispielen!
> Habe einiges daraus gelernt.

Freut mich, das mein "Zeug" immer noch hilfreich ist.

> Bzgl.Debugging: Ich erhalte keinen Fehler, dort wo man aber
> normalerweise Haltepunkte setzen kann (grauefarbene Rechtecke) sind
> entweder keine oder sie sind irgendwo verstreut. Ein elf-File wird
> erzeugt. Vielleicht liegt es aber gar beim Code. Habe bereits ein paar
> Beispiel von verschiedenen Webseiten probiert.

Ist in den Compilereinstellungen die Erzeugung von Debug-Symbolen 
aktiviert? Wie lautet die Kommandozeile für gcc, die uVision unten im 
Einstellungsdialog anzeigt?

> Anbei das Beispiel. Ist sogar Quellcode von dir dabei:)

Im Moment auf keinem Rechner mehr uVision installiert. Werde die 
aktuelle Eval.-Version bei nächster Gelegenheit herunterladen und 
ausprobieren.

> Bei Keil ist man bestimmt wenig daran interessiert, dass gcc in uVision
> funktioniert. Habe aber dort schon nachgeschaut.

Muss nicht sein. Der "Mutterkonzern" ARM hat jüngst mitgeteilt, dass man 
aktiver an den GNU-Tools mitarbeiten werde. Es gab zumindest von Keil 
auch eine Application-Note wie uVision für die Codesourcery Binaries 
einzurichten ist. Hatte vor längerem auch kleinere Verbessungsvorschläge 
gemacht, die bei Keil auch auf offene Ohren stießen.

[Geri (Gast)]

Hallo Martin

>Freut mich, das mein "Zeug" immer noch hilfreich ist.
Ich hoffe, es geht so weiter:)

>Ist in den Compilereinstellungen die Erzeugung von Debug-Symbolen
>aktiviert? Wie lautet die Kommandozeile für gcc, die uVision unten im
>Einstellungsdialog anzeigt?

Ich meine schon. gcc werden folgende Parameter übergeben:

-c -mcpu=cortex-m3 -mthumb -g -gdwarf-2 -MD -Wall -O0 -mapcs-frame  -I.\Core\CM3 -I.\inc\syscalls -IC:\Programs\yagarto\INC\NXP\LPC17xx\ -Wa,-alhms=".\obj\*.lst" -o *.o

>Muss nicht sein. Der "Mutterkonzern" ARM hat jüngst mitgeteilt, dass man
>aktiver an den GNU-Tools mitarbeiten werde. Es gab zumindest von Keil
>auch eine Application-Note wie uVision für die Codesourcery Binaries
>einzurichten ist. Hatte vor längerem auch kleinere Verbessungsvorschläge
>gemacht, die bei Keil auch auf offene Ohren stießen.

Kommt wahrscheinlich auch immer darauf an, wer dort anklopft:)

Beste Grüsse
Geri