The reason for the multitude of "VDD monitor enables" is to ensure that if the program counter gets into the flash routine accidentally, from errant CPU operation due to a power failure for example, the VDD monitor has a chance to reset the device before a potential flash corruption event. This can happen if the VDD monitor was accidentally disabled earlier in the code.

Regarding Bert's problem, if the VDD monitor was off prior to entry into WriteFlashByte, the order of "enable VDD monitor as reset source" followed by "enable VDD monitor" could cause a reset event if the VDD monitor "bounced" as it was coming up. That's why we recommend a delay between enabling the VDD monitor and enabling it as a reset source, to prevent spurious resets. HOWEVER, we recommend that the delay be removed if code contains routines that write or erase flash memory.

I'd recommend enabling the VDD monitor at the beginning of code and leaving it on, with no further writes to VDM0CN. I'd also recommend removing the "mov RSTSRC, #00h", as this disables the VDD mon as a reset source.

Also, flash write and erase operations will fail if targeting an invalid address. You might confirm the dptr register contents prior to execution of the movx @dptr, a instruction.

If you are implementing a bootloader, you might consider putting part of the bootloader in the flash page containing the Lock byte (the page right before the end of flash). That page cannot be erased by firmware.

-Brent