MSP430F5418A hangs at 0DCDCC ---- when debug

 common reason why the processor runs wild and jumps into the field is that you enable an interrupt but do not have an ISR for this interrupt. Then the processor will read '0xffff' from the vector table and starts executing code at 0xfffe (whcih is the reset vector and no isntruction). Based on what it finds next, it can basically do everything. Including a jump into a location where there is no flash (and the flash controller will emit 0x3fff, a 'JMP $' instruction).

Another possible reason is a stack overflow or stack corruption. First happens when the program nesting level (or excessive use of local variables) lets the stack grow into the global variables area, the second when using pointers incorrectly, or writing to arrays with an index far beyond the reserved range. In both cases you may write random values to the stack, and when returning from a function, the return address form the stack has been changed and hte processor 'returns' to somewhere else.

A third reason (which shouldn't happen) is when large and small code memory address mdoels are mixed. Then a funciton that calls a second will put two bytes return address on the stack, but the called function will fetch a 4 byte return address or v.v.
Also, interrupt functions must be in the lower 64k of memory.  However, the compiler/linker should normally take care of this and complain if things do not fit together. Hand-made assembly or inline assembly code, however, won't be checked under all circumstances.