msp430gcc4 / Eclipse / Sampel code MSP430F499stk2

Nur Resets? Wo siehst du die? Eventuell ist der Watchdog nicht schlafen 
gelegt? Ich hab jetzt nicht das ganze Ding angeschaut, aber bei großen 
RAM Arrays kann es passieren, dass der WDT zuschlägt, bevor der 
C-Startup Code das Array initialisiert hat. In dem Fall muss man den WDT 
Stop in eine Section packen, die vor dem Startup ausgeführt wird.

Hi supachris,

laut Code ist der WD zuerst deaktiviert:
http://dev.ivanov.eu/projects/msp430-449stk2_sample/449stk2_8c-source.html#l00953

dann werden mit dem WDT die Sekundenpulse erzeugt
http://dev.ivanov.eu/projects/msp430-449stk2_sample/449stk2_8c-source.html#l00296

Der Reset ist eine Vermutung.
Der Startvorgang mit dem Original Code ist wie folgt:
- LCD alles an
- LED 2x kurzes Aufblinken
- Sound
- Anzeige Uhr
- Uhr läuft - Sekundenzeiger zählt


Mit meinem Code wiederholt sich folgendes ca. jede Sekunde.
- LCD sehr kurz an
- LED sehr kurz an (nur 1x)
- kurzer Sound
Display aus und ca. 1 Sek wieder von vorn


Den Debugger habe ich gemäß o.g. Anleitung eingerichtet, doch er lädt 
den Code nicht rüber und ein debugging ist damit leider nicht möglich.
Die elf-files kann ich deshalb nur manuell auf das target laden.

Ich könnte mal versuchen hier
http://dev.ivanov.eu/projects/msp430-449stk2_sample/449stk2_8c-source.html#l01036
vor dem

1

01036     RTC_init ();

ein längeres Delay einzubauen um zu sehen ob die Initialisierung korrekt 
funktioniert.

Irgendwie vermute ich aber die compiler, linke, debugger Einstellungen 
sind nicht korrekt. Kennst Du dich damit aus?

Grüße
JR

Also,
habe einen Sound als akustischen Trigger einbaut um zu hören & sehen 
wann dieser noch ausgeführt wird bevor es einen Reset gibt.

Ergebnis:
Genau bis hierhin wird er noch ausgeführt:
http://dev.ivanov.eu/projects/msp430-449stk2_sample/449stk2_8c-source.html#l00408
vor

1

00408         incrementSeconds ();

setze ich den Soundtrigger nach incrementSeconds, dann wird er nicht 
mehr ausgeführt, sondern das Programm startet von vorne.

incrementSeconds ist in rtc_calendar.s (siehe Anhang) definiert:

1

;============================================================================

2

; incrementSeconds

3

;============================================================================

4

.global incrementSeconds

5

incrementSeconds:

6

            clrc

7

            dadd.b  #0x01,   &TI_second     ; tick one second

8

            cmp.b   #0x60,   &TI_second     ; see if we've hit 60 seconds

9

            jne     return                  ; if not, return

10

            clr.b   &TI_second              ; if so, go back to 00

11

                                            ; fall down to increment minutes

Irgendeine Idee was das Programm zum Absturz bringt?

Zum Debuggen brauchst du noch die msp430-gdbproxy.exe aus dem MSPGCC 3. 
Ist in der 4er Version nicht enthalten. Dann sollte es gehen. Entgegen 
den Anleitungen muss mit den aktuellen GBD Versionen das Elf File in der 
gdb-target.ini mit / angegeben werden. Also

load Debug/File.elf

Und diese ganzen target remotesizeaddress usw. müsen raus. In der ini 
für den GDB steht höchstens noch:

target remote localhost:3333
monitor erase main
load Debug/file.elf

Dann sollte es klappen.

Vielen Dank für die response.
Die msp430-gdbproxy.exe ist schon die ältere Version (2006-11-14).

Benutze den JTAG parallel

1

--port=3333 msp430

Kommunikation via Proxy steht. Er erkennst das target und und der erase 
funktioniert ebenfalls.
Nur das schreiben nicht. Werde also deine Idee mit dem Weglassen der

1

set remoteaddresssize 64

2

set remotetimeout 999999

in der

1

gdb-target.ini

ausprobieren.

Da sich der Effekt auf den Assemblerteil (rtc_calendar.s) bezieht, kann 
es sein, dass ich noch was bei den GCC Assembler Einstellungen was 
ändern sollte? Zusätzliche Flags? (siehe Bilder im Anhang)

oder
liegt evtl ein Problem mit den WDT Interrupt Vektoren oder der ISR 
(Interrupt Service Routine) vor?

Grüße

Nimm mal den Proxy aus der Version vom 30.12.2008. Manche Versionen 
hatten echt komische Bugs. Der 2008er funktioniert bei mir mit allen 
aktuellen Chips, die ich bisher hatte. Und den / statt \ in der Ini 
nicht vergessen.
Wegen assembler bin ich überfragt, hab ich am MSP430 noch nie machen 
müssen. Kann schon sein, dass der da irgendwie die Vektoren nochmal 
überschreibt oder so...schreib den Quatsch doch in C, das ASM bringt am 
MSP430 in den allerwenigsten Fällen was.

Habe gerade nachgeschaut, verwende bereits den proxy der 2008-12-30 
Version.
Die "set remote.." habe ich entfernt.

Beim Debuggen zeigt console:

1

debug: MSP430_Initialize()

2

debug: MSP430_Configure()

3

debug: MSP430_VCC(3000)

4

debug: MSP430_Identify()

5

info:      msp430: Target device is a 'MSP430F44x' (type 14)

6

debug: MSP430_Configure()

7

notice:    msp430-gdbproxy.exe: waiting on TCP port 3333

8

notice:    msp430-gdbproxy.exe: connected

9

debug: MSP430_Registers(READ)

10

debug: MSP430_Registers(READ)

11

debug: MSP430_Memory(READ)

12

debug: command '657261736520616c6c'

13

debug: command 'erase all'

14

debug: executing target dependant command 'erase'

15

debug: MSP430_Memory(WRITE)

16

debug: MSP430_Memory(WRITE)

17

debug: MSP430_Memory(WRITE)

...hab hier ca. 130 Wiederholungen gelöscht...

1

debug: MSP430_Memory(WRITE)

2

debug: MSP430_Memory(WRITE)

3

debug: MSP430_Memory(WRITE)

4

debu

und er bleibt bei 27% hängen.

Als Debugger verwende ich
C:\MSPGCC4\bin\msp430-gdb.exe
mit den 'initialize' commands

1

target remote localhost:3333

2

monitor erase all

3

load debug/20110606.elf

(20110606 ist der Projektname)

Debugger und Proxy Einstellungen sind als Screenshot angefügt.
Passen die so?


Ich möchte das ganze nicht in C portieren, da ich die files von TI 
verwenden möchte:
http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=slaa290a

Grüße

Sieht eigentlich erst mal OK aus. Aber in deinem Post vom 07.06.2011 
08:25, stimmt der Prozessortyp in den Projektoptionen nicht mit deinem 
F449 überein. Hast du das korrigiert? Ich verwende zwar kein Zylin, 
sondern den normalen Eclipse Debugger mit GDB-Server Einstellung, aber 
der Zugriff klappt ja offenbar.

Ja ist auf msp430x44x eingestellt.
Das Bildchen war von der Anleitung.

Mit den o.g. Einstellungen funktioniert der Debugger prinzipiell, da ich 
ihn mit einem einfachen Testprogramm (LED toggeln) getestet habe.

Ich vermute es hat mit dem ASM Code Teil zu tun.

Habe versucht die ASM files aus dem u.g. Beispiel für den MSP430GCC4 
anzupassen, doch leider ohne Erfolg.

http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=slaa290a

Kann jemand helfen?

Die asm-files sind anbei