Hallo zusammen,
ich bin noch recht neu in der Mikrocontroller-Programmierung und
bräuchte ein wenig Hilfe mit einem Problem, das ich absolut nicht
einordnen kann:
Ich arbeite mit einem TelosB, auf dem ein MSP430F1611 verbaut ist, und
dem MSPGCC. Zum Flashen meiner Programme verwende ich tos-bsl (eine
Abwandlung des msp430-bsl Bootstrap Loaders für TelosB Motes aus der
TinyOS-Toolchain).
Als ich ein UART-Testprogramm (von mathar.com, s. Anhang), dessen
Interruptroutinen ich auf den MSPGCC angepasst habe, ausprobieren
wollte, erhielt ich folgende Ausgabe:
<snip>
D:\Code\ITM\telosb\InterruptTest>make
msp430-gcc -Os -mmcu=msp430x1611 -c InterruptTest.c -o InterruptTest.elf
msp430-objcopy -O ihex InterruptTest.elf InterruptTest.ihex
tos-bsl --telosb -c 5 -r -e -I -p InterruptTest.ihex
MSP430 Bootstrap Loader Version: 1.39-telos-8
Mass Erase...
Transmit default password ...
Invoking BSL...
Transmit default password ...
Current bootstrap loader version: 1.61 (Device ID: f16c)
Changing baudrate to 38400 ...
Program ...
An error occoured:
Unknown header 0x00
Are you downloading to RAM into an old device that requires the patch?
Try optio
n -U
make: *** [InterruptTest.ihex] Error 1
</snip>
Das Auftauchen dieses Problems ist scheinbar willkürlich, denn für
unterschiedliche mit dem MSPGCC kompilierbare (!) Programme tritt der
Fehler manchmal auf und manchmal nicht. Wichtig hierbei ist, dass der
Fehler reproduzierbar bleibt, sich ein und dasselbe Programm also
entweder immer flashen lässt oder aber nie.
Es gab auch den Fall, dass sich ein Programm flashen ließ, in dem die
Anweisung P1DIR |= 0x01; vorkam. Verdoppelte man diese Anweisung jedoch
(führte also einen syntaktischen, aber keinen semantischen Unterschied
herbei), ließ sich das Programm nicht mehr flashen und hatte wieder den
o.g. Fehler zur Folge.
Mir fehlt wirklich jeglicher Ansatz, um dem Ursprung des Problems auf
die Schliche zu kommen. Hoffentlich seid ihr da kreativer.
Vielen Dank für Eure Ideen!
Beste Grüße,
Florian
Also da sind mehrere Fehler im Quelltext, du müsstest mindestens eine
Warnung bekommen. Was passiert wohl, nachdem der 1. Interrupt
eingetreten ist? Rrrungs, und der µC landet im Nirvana. Desweiteren hast
du eventuell RX-Int und TX-Int verwechselt, geht aus den Kommentaren
nicht eindeutig hervor. Und die Meldung, dass er versucht 38400 Baud zu
machen, heißt nix gutes. Ich hab das nie hinbekommen, geht nur mit 9600.
Irgendwie scheints da Inkompatibilitäten zu geben.
Hallo Christian,
wie gesagt habe ich den Quelltext nur kopiert, um mal auszuprobieren,
wie die Kommunikation per Terminal und UART überhaupt abläuft. Warnungen
gibt der MSPGCC nicht aus, das Programm wird fehlerlos übersetzt.
Mein Problem ist wie beschrieben (noch) nicht die Programmierung,
sondern das Flashen. Und: Da es Fälle gibt, in denen das Flashen
problemlos funktioniert, würde ich mich wundern, wenn die Ursache die
Baudrate wäre. Wie sollte das mit der geschilderten Fehlermeldung
zusammenpassen?
Ich freue mich über jegliche weitere Gedanken zur Problematik!
Vielen Dank für die Mühe,
Florian
Vielleicht stimmt was mit dem Hex-File nicht? Der Header könnte da ja
aus dem Hex-File sein. Nichts desto trotz wird dein Programm sowieso
nicht funktionieren.
@Christian:
Ja, zumindest erwartet tos-bsl offenbar (manchmal) etwas anderes als
das, was msp430-obj als ihex fabriziert. Derzeit bin ich auf der Suche
nach ner Application Note o.ä., die beschreibt, wie das Programmformat
aussehen muss, damit ich von Hand debuggen kann.
@Wolfgang-G:
Eine Blinkanwendung war das erste Programm, das ich ausprobiert habe.
Das funktionierte anstandslos.
Der Vollständigkeit halber wollte ich nur mitteilen, dass das Problem
gelöst wurde. Ursache für die Fehlermeldung war ein verkehrt
geschriebenes Makefile, das eine fehlerhafte ihex-Datei erzeugt hat.
Eine eigene Frage?
Dieser Thread ist über 18 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
