MSP430 flash löscht sich?

Also, den Code ist der Originale von TI, nichts geändert!
Hier auch als Anhang.
Sieht genau gleich aus wie Beispiele für andere MSP430.

Also ich sehe diese Fehlermöglichkeiten:

1. Du hast das Flash gar nicht beschrieben
2. Du überschreibst das Flash selber wieder unerwartet
3. Durch den Einsatz des Debuggers wird das Flash überschrieben
4. Du läufst in einen Hardwarebug des MSP430F5XXX (Interrupts müssen 
während des Löschvorgangs ausgeschaltet sein)

Zieh mal lieber die Codebeispiele zum MSP430F5XXX zu Rate:
http://www.ti.com/litv/zip/slac166j

Er meint wohl, dass er eine eigene Speisung hat und nicht die des 
Debuggers verwendet.

@ A.K. Genau was Johnny sagt

Ich hab den Code erweitert mit eine Test routine, um tatsächlich den 
Wert aus Flash zu lesen.

1

//FOR TESTING

2

  //initialize variables and pointers

3

  char *Flash_ptrC;

4

  char *Flash_ptrD;

5

  char testvalue1 = 0;

6

  char testvalue2 = 0;

7

  Flash_ptrC = (char *)0x1040;

8

  Flash_ptrD = (char *)0x1000;

9

10

  //store flash value in variable

11

  testvalue1 = *Flash_ptrC;

12

  testvalue2 = *Flash_ptrD;

13

14

//END TESTING

Siehe Anhang: Printscreens (01 - Writing on flash) (02-checking value on 
flash)

und zweites Printscreen

@ Johnny

1. nach ein Test sieht nicht so aus
2. Ich hab ein Breakpoint und die option "leave target running" gelöscht
3. Die erwähnten Optionen ("Flash erase option") habe ich auf "Erase 
main Memory" und nicht erase Information Memory (wie von Rufus gesagt)
4. Ich arbeite mit ein F2132

Ich vermute doch etwas mit den Punkt 3, aber weiss nicht was das problem 
sein könnte :(

Schalte ich die Speisung ab, entferne der debugger und starte von neu 
aus...
ein schreckliches Resultat!

Segment D ist gelöscht
Segment C hat irgend ein Random Wert

(würde der Code alleine weitergehen, würden die 2 Segmente den gleichen 
Wert haben !)

Deine Screenshots legen nahe, dass Du möglicherweise im Single-Stepping 
Mode durch Deinen Code durchläufst. Das kann während des 
Flash-Programmings tödlich sein.

Siehe hierzu auch einen Auszug aus den FAQs des TI-FET:

21. When programming the flash, do not set a breakpoint on the 
instruction immediately followingthe write to flash operation. A simple 
workaround to this limitation is to follow the write to flash operation 
with a NOP, and set a breakpoint on the instruction following the NOP 
(see FAQ Debugging
#23).

23. Multiple internal machine cycles are required to clear and program 
the flash memory. When single stepping over instructions that manipulate 
the flash, control is given back to C-SPY before these operations are 
complete. Consequently, C-SPY updates its memory window with erroneous 
information. A workaround to this behavior is to follow the flash access 
instruction with a NOP, and then step past the NOP before reviewing the 
effects of the flash access instruction (see FAQ Debugging #21).

und:

19. C-SPY utilizes the system clock to control the device during 
debugging. Therefore, device counters, etc., that are clocked by the 
Main System Clock (MCLK) are affected when C-SPY has control of the 
device. Special precautions are taken to minimize the effect upon the 
Watchdog Timer. The CPU
core registers are preserved. All other clock sources (SMCLK, ACLK) and 
peripherals continue to operate normally during emulation. In other 
words, the Flash Emulation Tool is a partially intrusive tool.
Devices that support clock control (Emulator ® Advanced ® Clock Control) 
can further minimize these effects by selecting to stop the clock(s) 
during debugging (see FAQ Debugging #24).

irgendwie hast du recht Stefan.
Ich bin den Beispielcode vorbeigegangen und habe ein "Flash manager" in 
mein Code eingebaut und es funktioniert makellos.

Es geht ein bisschen gegen mein Kredo "probieren mit Beispiel, verstehen 
und einbauen" aber naja, diesmal hat es funktioniert...

Danke nochmals für euren Einsatz!