With some versions of CCS6 compilers, some EVM codes will reset when data flash write is attempted. This can be fixed by reducing the optimization down to low levels, but this leads to increase code size and slower execution.
The root cause is that the MFBALR2 register used in the data flash write is not designed for byte writes. If bitwise structures are used with higher optimization levels, the compiler will sometimes optimize to byte reads and writes. To prevent this, don't use bitwise structures.
The bitwise structure statement used in this case is:
DecRegs.MFBALR2.bit.RONLY = 0;
This statement clears the read only bit so that the data flash can be written. Normally this bit is kept set to help protect the data flash.
Sometimes this also is found:
DecRegs.MFBALR2.bit.BLOCK_SIZE =2;
DecRegs.MFBALR2.bit.ADDRESS = 0x22;
These two are unnecessary, because these bits are already configured correctly.
They are a translation of the original statement into bitwise structures:
DecRegs.MFBALR2.all = 0x8820; //for all but UCD3138128
The 88 in this statement is the same as the 22 in the bitwise statement. It sets the lower bits of the address to 8800. On the UCD3138128, the data flash is at a different location, so it should be 0x9820;
DecRegs.MFBALR2.all = 0x9820; //for UCD3138128
After the data flash is written, there is another statement:
DecRegs.MFBALR2.bit.RONLY = 1;
This can also cause problems in the same way, so it should be replaced with:
DecRegs.MFBALR2.all = 0x8822; //for all but UCD3138128
or:
DecRegs.MFBALR2.all = 0x9822; //for UCD3138128
Changing to a 2 in the least significant nybble set the RONLY bit to put the protection back in place.
Any other uses of the MFBALR and MFBAHR registers could also have this issue.
The only other use which comes to mind in for on-the-fly switching of firmware versions, using the multiple remappable flash blocks on the '64 and '128 versions.