I realize this post is nearly 2 years old, but I had a similar issue and wanted to post the solution.
The BWT causes the MCU to reset during the flash erase because the BWT timer continues to run in debug mode, and the erase procedure takes longer than the BWT timeout. To avoid this, you can setup the debugger configuration script to disable the BWT when it initially connects to the MCU, before the flash operations take place. CodeWarrior uses .cfg scripts loaded by the debugger to setup the MCU before code is downloaded.
Attached is a project created for the M52259EVB using CodeWarrior v10.2. The project uses Processor Expert to initialize the BWT with a timeout of 102.4us. And the application does not service the watchdog, so it continually resets. After this program is loaded in the flash and runs, if the debugger is used a second time to reprogram the flash, CW gives debugger error messages.
The file \M52259EVB_BWT\Project_Settings\Debugger\MCF52259.cfg was modified by adding the lines below. This line disables the watchdog shortly after the debug communication is established, and prevents the resets from occurring during flash programming.
; Disable BWT Watchdog, WCR = 0x0002
writemem.w 0x40140000 0x0002
One thing to note, is that the WCR is a write-once register. If the .cfg script writes to this register during debug, then the firmware that executes in the debugger will not be able to change it. Keep this in mind as you debug because application code intending to enable the BWT may appear to run fine with the debugger, and then get watchdog resets when booted without the debugger. If needed, you can setup two different Debug Connections in CW, using two different .cfg scripts: one that disables the watchdog for programming, and the other that does not write to the WCR register, allowing the application to enable the BWT in the debugger.
Also, the .cfg script files can also be used with Classic CodeWarrior, for versions before v10.0.
