Forum: Mikrocontroller und Digitale Elektronik TI Launchpad MSP430


von Felix G. (felix_g87)


Lesenswert?

Hallo,


ich muss dieses Wochenende noch eine Schaltung mit dem TI LaunchPad 
aufbauen, und habe ein Problem bei der Programmierung.
Ich habe funktionsfähigen C-Code kompiliert mit MSP-GCC in CodeBlocks 
mit

-Os -mmcu=msp430g2553 -o  DeadMan.c

und

msp430-objcopy -O ihex 
C:\Users\gradf_000\Desktop\DeadMan\DeadMan\obj\Release\DeadMan.o 
C:\Users\gradf_000\Desktop\DeadMan\DeadMan\obj\Release\DeadMan.hex   als 
PostBuildStep.

Der FET-Programmierer von Elprotronic meldet mit der erzeugten .hex dann 
"Data outside flash space". Wo liegt mein Fehler?


Danke im Voraus,
Felix

von Walter (Gast)


Lesenswert?

Felix G. schrieb:

> Der FET-Programmierer von Elprotronic meldet mit der erzeugten .hex dann
> "Data outside flash space". Wo liegt mein Fehler?

Der Fehler sagt, dass du versuchst Adressen anzusprechen die oberhalb 
deines Adressraum liegen. Wo dein Fehler kann ich naturgemäß nicht 
sagen, da dazu die Informationen nicht ausreichen. Es könnte z. B. sein, 
dass dein Programm (und damit dein Zielcode) zu lang geworden ist.

von Felix (Gast)


Lesenswert?

1
#include  <C:\Program Files\mspGCC\msp430\include\msp430g2553.h>
2
3
unsigned int currentMinutes, currentSeconds;
4
5
void main(void)
6
{
7
  WDTCTL = WDTPW + WDTHOLD;      // Stop WDT
8
9
  BCSCTL1 |= DIVA_3;        // ACLK/8
10
  BCSCTL3 |= XCAP_3;        //12.5pF cap- setting for 32768Hz crystal
11
12
  P1DIR |= BIT0;          // set P1.0 (LED1) as output
13
  P1OUT |= BIT0;          // P1.0 low
14
15
  currentMinutes = 0;
16
  currentSeconds = 0;
17
18
  CCTL0 = CCIE;          // CCR0 interrupt enabled
19
  CCR0 = 511;          // 512 -> 1 sec, 30720 -> 1 min
20
  TACTL = TASSEL_1 + ID_3 + MC_1;      // ACLK, /8, upmode
21
22
  _BIS_SR(LPM3_bits + GIE);      // Enter LPM3 w/ interrupt
23
}
24
25
// Timer A0 interrupt service routine
26
#pragma vector=TIMER0_A0_VECTOR
27
__interrupt void Timer_A (void)
28
{
29
  P1OUT ^= BIT0;          // Toggle LED
30
}


und die .hex :

1
:0A0000000F12D2E300003F4100138D
2
:10000000B240805A0000F2D030000000F2D00C0064
3
:100010000000D2D30000D2D300008243000082430C
4
:100020000000B24010000000B240FF010000B240EA
5
:08003000D001000032D0D8001D
6
:00000001FF

von Marco S (Gast)


Lesenswert?

Sollte es nicht

msp430-objcopy -O ihex
C:\Users\gradf_000\Desktop\DeadMan\DeadMan\obj\Release\DeadMan.c
...

heißen, wenn du das binary komischerweise in die Datei "DeadMan.c" 
schreibst.

von Felix (Gast)


Lesenswert?

Leider nichts. Der Hex-Code bleibt gleich. Außerdem habe ich bemerkt, 
dass eine .exe erzeugt wurde (darin befindet sich kein hex-code).

von Marco S (Gast)


Lesenswert?

Vielleicht objcopy auf diese exe loslassen?

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Felix schrieb:
> #include  <C:\Program Files\mspGCC\msp430\include\msp430g2553.h>

Bei einem ordnungsgemäß installierten Compiler sollte der #include-Pfad 
korrekt gesetzt sein, so daß hier keine absolute Pfadangabe nötig ist.

> #include  <msp430g2553.h>
1
  n offs t  data                             cs
2
:0A 0000 00 0F12D2E300003F410013             8D
3
:10 0000 00 B240805A0000F2D030000000F2D00C00 64
4
:10 0010 00 0000D2D30000D2D30000824300008243 0C
5
:10 0020 00 0000B24010000000B240FF010000B240 EA
6
:08 0030 00 D001000032D0D800                 1D
7
:00 0000 01 FF
8
9
n     Anzahl Bytes im Datensatz
10
offs  Adresse, an die das erste Datenbyte der Zeile geladen 
11
      werden soll
12
t     record type (0 = Daten, 1 Ende)
13
data  Nutzdaten
14
cs    Prüfsumme

Das liegt tatsächlich außerhalb des Flash-Adressraums.

Beim 'G2553 liegt das Flash von 0xC000 - 0xFFFF, die obersten 64 Bytes 
sind die Interruptvektoren (0xFFC0 - 0xFFFF).

Dieses Hex-File hier aber schreibt in der ersten Zeile 10 Bytes an die 
Adresse 0x0000, und mit der zweiten bis vierten Zeile 56 Bytes wieder an 
Adresse 0x0000.

von Felix (Gast)


Lesenswert?

Okay, Pfad relativ include und lib ordner sind definiert. Aber immer 
noch die gleiche hex. Ich bin am verzweifeln....

von linker Linker (Gast)


Lesenswert?

Hmmm, muss man dem Linker nicht auch den Typ mitteilen? Er setzt 
schließlich die Adressen ein.

Fehlt nicht auch die Runtimelib? Das Ganze sieht im Ergebnis unfertig 
aus.

von Marco S (Gast)


Lesenswert?

Kannst du denn mit

msp430-objdump -dSz xxx.x

in einer Shell die einzelnen Dateien anschauen.

Wenn ich bei mir mit avr-gcc aus
1
int main(void)
2
{
3
        return 0;
4
}

ein main.o und main.elf erzeuge, bekomme ich mit avr-objdump -dSz main.o
1
main.o:     file format elf32-avr
2
3
4
Disassembly of section .text.startup:
5
6
00000000 <main>:
7
8
int main(void)
9
{
10
        return 0;
11
12
}
13
   0:   80 e0           ldi     r24, 0x00       ; 0
14
   2:   90 e0           ldi     r25, 0x00       ; 0
15
   4:   08 95           ret

Zeugs, dass an Adresse 0 beginnt und nur das return 0 beinhaltet. Mit 
avr-objdump -dSz main.elf folgt
1
main.elf:     file format elf32-avr
2
3
4
Disassembly of section .text:
5
6
00000000 <__vectors>:
7
   0:   19 c0           rjmp    .+50            ; 0x34 <__ctors_end>
8
   2:   20 c0           rjmp    .+64            ; 0x44 <__bad_interrupt>
9
   4:   1f c0           rjmp    .+62            ; 0x44 <__bad_interrupt>
10
   6:   1e c0           rjmp    .+60            ; 0x44 <__bad_interrupt>
11
   8:   1d c0           rjmp    .+58            ; 0x44 <__bad_interrupt>
12
   a:   1c c0           rjmp    .+56            ; 0x44 <__bad_interrupt>
13
   c:   1b c0           rjmp    .+54            ; 0x44 <__bad_interrupt>
14
   e:   1a c0           rjmp    .+52            ; 0x44 <__bad_interrupt>
15
  10:   19 c0           rjmp    .+50            ; 0x44 <__bad_interrupt>
16
  12:   18 c0           rjmp    .+48            ; 0x44 <__bad_interrupt>
17
  14:   17 c0           rjmp    .+46            ; 0x44 <__bad_interrupt>
18
  16:   16 c0           rjmp    .+44            ; 0x44 <__bad_interrupt>
19
  18:   15 c0           rjmp    .+42            ; 0x44 <__bad_interrupt>
20
  1a:   14 c0           rjmp    .+40            ; 0x44 <__bad_interrupt>
21
  1c:   13 c0           rjmp    .+38            ; 0x44 <__bad_interrupt>
22
  1e:   12 c0           rjmp    .+36            ; 0x44 <__bad_interrupt>
23
  20:   11 c0           rjmp    .+34            ; 0x44 <__bad_interrupt>
24
  22:   10 c0           rjmp    .+32            ; 0x44 <__bad_interrupt>
25
  24:   0f c0           rjmp    .+30            ; 0x44 <__bad_interrupt>
26
  26:   0e c0           rjmp    .+28            ; 0x44 <__bad_interrupt>
27
  28:   0d c0           rjmp    .+26            ; 0x44 <__bad_interrupt>
28
  2a:   0c c0           rjmp    .+24            ; 0x44 <__bad_interrupt>
29
  2c:   0b c0           rjmp    .+22            ; 0x44 <__bad_interrupt>
30
  2e:   0a c0           rjmp    .+20            ; 0x44 <__bad_interrupt>
31
  30:   09 c0           rjmp    .+18            ; 0x44 <__bad_interrupt>
32
  32:   08 c0           rjmp    .+16            ; 0x44 <__bad_interrupt>
33
34
00000034 <__ctors_end>:
35
  34:   11 24           eor     r1, r1
36
  36:   1f be           out     0x3f, r1        ; 63
37
  38:   cf ef           ldi     r28, 0xFF       ; 255
38
  3a:   d4 e0           ldi     r29, 0x04       ; 4
39
  3c:   de bf           out     0x3e, r29       ; 62
40
  3e:   cd bf           out     0x3d, r28       ; 61
41
  40:   02 d0           rcall   .+4             ; 0x46 <main>
42
  42:   04 c0           rjmp    .+8             ; 0x4c <_exit>
43
44
00000044 <__bad_interrupt>:
45
  44:   dd cf           rjmp    .-70            ; 0x0 <__vectors>
46
47
00000046 <main>:
48
49
int main(void)
50
{
51
        return 0;
52
53
}
54
  46:   80 e0           ldi     r24, 0x00       ; 0
55
  48:   90 e0           ldi     r25, 0x00       ; 0
56
  4a:   08 95           ret
57
58
0000004c <_exit>:
59
  4c:   f8 94           cli
60
61
0000004e <__stop_program>:
62
  4e:   ff cf           rjmp    .-2             ; 0x4e <__stop_program>

die Information, dass Startup- und Interruptcode in der main.elf 
stecken.

von Felix (Gast)


Lesenswert?

Welche Optionen hast Du deinem Compiler und linker übergeben? Ich 
vermute, dass der Fehler da liegt.

von Marco S (Gast)


Lesenswert?

1
avr-gcc -Os -mmcu=atmega88 -g -c main.c
2
avr-gcc -Os -mmcu=atmega88 -o main.elf main.o

Was mich halt wundert, du schickst die Ausgabe (-o) nach DeadMan.c. 
Kannst du denn die DeadMan.o und DeadMan.exe hier hochladen?


Der Versuch
1
>cp main.c xmain.c
2
>avr-gcc -Os -mmcu=atmega88 -o xmain.c xmain.c
3
>file xmain.c
4
xmain.c: ELF 32-bit LSB executable, Atmel AVR 8-bit, version 1 (SYSV), statically linked, not stripped
zeigt auf, das gcc die Source-Datei überschreibt.

von nchp (Gast)


Lesenswert?

>Fehlt nicht auch die Runtimelib? Das Ganze sieht im Ergebnis unfertig
>aus.

Ist ja auch kein Wunder, wenn er  - vermutlich - gar nicht linkt 
(ausweislich des
ersten Postings) und gleich das .o dem objcopy vorwirft...
Da aber seine Angaben nur fragmentarisch sind...


Und bleibt weg mit avr, das verwirrt den OP nur.
Sinngemäss passt der Vorschlag von  Marco S. aber.

Bitte 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
Noch kein Account? Hier anmelden.