TI Launchpad MSP430

Felix G. #3740778
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
Beitrag melden Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Markierten Text zitieren Antwort Antwort mit Zitat
Walter Gast #3740784
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.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Felix Gast #3740801
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
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Rufus Τ. F. Persönliche Seite #3740853
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.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Marco S Gast #3740937
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.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Marco S Gast #3741049
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.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
nchp Gast #3741489
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.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren