Hallo,
ich möchte ein kleines Programm für den MSP430G2231 in Assembler
schreiben. Dazu hab ich hier in den Foren schon mal etwas gesucht und
folgenden Quelltext zusammengebaut:
1
#include <msp430.h>
2
.section .text
3
RESET: mov.w #0x0280,R1 ; Initialize stackpointer - End of RAM
d:/mspgcc/bin/../lib/gcc/msp430/4.6.1/../../../../msp430/bin/ld.exe: asm.o section `.vectors' will not fit in region `vectors'
2
d:/mspgcc/bin/../lib/gcc/msp430/4.6.1/../../../../msp430/bin/ld.exe: region `vectors' overflowed by 32 bytes
3
collect2: ld returned 1 exit status
Demnach wäre die erlaubte Größe der Section .vectors ja 0 Byte groß. Ein
Disassembly des gleichen Programms in C hat Interruptvektortabelle
allerdings.
Das Kompilieren und Linken mit folgendem Aufrug funktioniert zwar:
Ein msp430-objdump -D zeigt mir auch an, dass die Section .vectors da
ist.
Aber wenn ich die gelinkte Datei mit mspdebug brennen will, wird nur die
Section .text gebrannt, die Section .vectors nicht.
Die Vektortabelle enthält damit nur 0xffff, das Programm läuft damit
nicht los...
Hat jemand einen Tip für mich, wie ich das Programm "richtig"
kompilieren kann? Ich finde dazu keine Lösung...
Danke schonmal.
Du hast einen Konflikt mit dem C-Startup File, welches sich selbst um
die .vectors kümmert.
Mein Toolchain-Aufruf mit -nostartfiles verhindert, dass das C-Startup
zu dem ASM-File gelinkt wird:
-v soll anzeigen, was gcc wie aufruft.
.S (S groß) ist für ASM-Sourcen besser, .s (s klein) sind von GCC
erzeugte, temporäre ASM-Files, die ein make clean löscht!
Und das Batchfile (objdump) erzeugt als Ausgabe (led.txt)
(Der falsche Labelname __ctors_end statt RESET ist vielleicht ein Bug,
aber nicht relevant für die Funktion)
Das 1. Problem hast du ja selbst durch den expliziten Aufruf des Linkers
in den Griff bekommen. Wie gesagt, das geht auch durch einen Aufruf des
gcc mit besagter Option.
Zu dem 2. Problem: Wie das Programm vollständig in den MSP430
schaffen...
> Mit mspdebug schreib ich die a.out, die von msp430-ld erzeugt wird:>>> mspdebug rf2500> (mspdebug) prog a.out> Erasing...> Programming...> Writing 38 bytes to f800 [section: .text]...
Hier ist für mich klar mspdebug der Übeltäter, der die vorhandene
.vectors Section ignoriert. Eine Verwechselung a.out mit einer alten
Version ohne .vectors schliesse ich mal aus. Hast du ein anderes
Brenntool? Gibt es ggf. eine modernere Version des mspdebug als deine?
@Krapao
Danke für den Tip mit dem -nostartfiles, das Programm kann jetzt in
einem Schritt kompiliert und gelinkt werden.
Mir ist zumindest kein anderes Brenntool bekannt (für Texas Instruments
Launchpad). 0.18 ist auch die aktuelle Version, ich werd aber mal die
Entwicklungsversion aus dem git probieren...
Vielleicht bringt es was, das Problem im MSPDEBUG-Support Forum
(http://develissimo.com/forum/36/) anzusprechen.
Ich werde bei Gelegenheit auch mal versuchen, das auf meiner Hardware
nachzustellen.
Danke für den Link zum Forum, habe schon eine Anlaufstelle für
mspdebug-Support gesucht.
Ich habe dort ein Thema zum Problem eröffnet:
http://develissimo.com/forum/topic/83982
Inzwischen hat jemand herausgefunden, dass der Section .vectors das
LOAD-Flag fehlt.
http://develissimo.com/forum/post/179346/
Das war schon mal ein wichtiger Hinweis, nun ist die Frage, wie ich die
Section mit dem Flag LOAD markiere.
Zum IAR oder CCS Assembler findet man zwar eine große Menge Ergebnisse,
was die GCC-Toolchain angeht sieht es allerdings trübe aus.
Kann mir jemand einen Tip geben, ob es sich um einen Schalter von GCC
handelt oder ob die Anweisung im Quelltext stehen muss?
Sonst werd ich es morgen mal mit einer anderen Suchmaschine probieren,
der Marktführer muss ja nicht unbedingt die besten Ergebnisse liefern ;)
.section .vectors, "ax"
oder ganz ausführlich
.section .vectors, "ax", @progbits
wäre mein Tipp
GNU Assembler User Manual
http://sourceware.org/binutils/docs-2.15/as/Section.html#Section
Ist aber ungetestet. Ich habe heute abend mehr Zeit als gedacht
verbracht, um erstmal die Toolchain aufzusetzen.
Neu:
http://www.mikrocontroller.net/articles/MSPGCC#Einfaches_Assembler-Beispielprogramm
Das mit der Windows-Version von MSPDebug will ich auch noch mal
probieren. Gestern hatte ich dort aufgehört, weil ich keinen Treiber für
"Backchannel UART" (unbekanntes Gerät im Gerätemanager: MSP430
Application UART) fand.
Im Moment benutze ich das MSP430 Launchpad unter LMDE (Linux Mint Debian
Edition). mspgcc und mspdebug sind dort im Repository.
@Krapao
Für mspdebug unter Windows brauchst du den libusb-Treiber. Dieser
funktioniert soweit ich weiß aber nicht für das UART-Device.
Außerdem ist es nicht möglich, CodeComposer Studio und IAR Embedded
Workbench und mspdebug gleichzeitig auf einem PC zu benutzen, da die
beiden IDEs eigene Treiber mitbringen.
Auf dem Rechner hier habe ich mspdebug zum Laufen gebracht, nachdem ich
das UART-Gerät über den Gerätemanager deaktiviert habe (sonst kam eine
Meldung, dass das Gerät nicht gefunden wurde). Vielleicht hilft dir das
ja weiter.
Danke für den Tip mit den Flags im Quelltext! Ich habe es eben
ausprobiert und mspdebug hat die .vector Section mit auf den Controller
programmiert. Das Programm läuft auch wie erwartet.
Und ich habe inzwischen den
USB CDC drivers to use the back-channel UART on the LaunchPad or on the
eZ430 Emulator: http://processors.wiki.ti.com/images/7/71/EZ430-UART.zip
installieren können und habe jetzt gleichzeitig(!) und problemlos(!) die
libusb Treiber zum Debuggen mit MSPDebug und die MSP430 Application UART
Treiber für die serielle Kommunikation mit dem Launchpad unter Windows
XP am laufen.
Die Installation selbst:
1) libUSB Treiber installieren wie in der MSPDebug FAQ beschrieben
2) EZ430-UART.zip entpacken
3) Launchpad anstöpseln und Hardwareassistent zur .INF Datei im
EZ430-UART Ordner führen
4) Reboot
Als Terminalprogramm benutze ich noch Putty bei 2400 Baud. Hyperterminal
zickt bei der Einstellung der Schnittstelle. Die Schnittstelle unter der
das Launchpad erreichbar ist, sieht man im Gerätemanager unter COM/LPT
in Klammern hinter dem Eintrag MSP430 Apllication UART. Bei mir ist es
COM4.
Einem frohen Werkeln unter Windows oder Linux steht somit nix im Wege
:-)
Thread beobachten
Seitenaufteilung abschalten