Do you have CRP enabled? Have a look at the documentation in your SDK: docs/FirmwareDevelopmentDocumentation/index.html > SW Debug Considerations, there is paragraph that talks about CRP.
Exactly when do you disable the SWD functionality? Immediately after a reset when main gets control? Or a few milliseconds later? You may be able to re-flash your IC by using FlashMagic, which prior to a flash operation, resets the IC and tries to hold the ARM as quickly as possible. It is much faster than the LPCXpresso IDE.
Is there a way in the application logic of the firmware currently flashed in the chip, that will cause it to re-enable SWD debugging? Can that be provoked, after which you can flash again?
Did you include the msg module in your application and enable the diversity setting MSG_ENABLE_PREPAREDEBUG? Then you can force enabling the SWD functionality and halting the ARM core by sending an NDEF message with 1 MIME record using the payload 08h 00h.
If all this fails, or is not possible, then the only way out is to solder a new IC to your board.
Then I'm afraid the IC looks thoroughly bricked and beyond recovery.
Replace the IC - or the entire board, and adapt your firmware:
Either just add
Chip_Clock_System_BusyWait_ms(50);
before doing something possibly dangerous. This will give you a minimum window of opportunity of 50 ms to break in.
Better seems to have a look at the implementation of
void ResetISR(void)
in the tlogger application firmware (look in SDK 11 ALPHA), and copy the extra break-in possibility, conditional to the state of the wake-up push button: i.e. wait during startup for as long as the WAKEUP pin is low.
