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
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.
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 |
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.
Leider nichts. Der Hex-Code bleibt gleich. Außerdem habe ich bemerkt, dass eine .exe erzeugt wurde (darin befindet sich kein hex-code).
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.
Okay, Pfad relativ include und lib ordner sind definiert. Aber immer noch die gleiche hex. Ich bin am verzweifeln....
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.
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.
Welche Optionen hast Du deinem Compiler und linker übergeben? Ich vermute, dass der Fehler da liegt.
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.
>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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.