I ran into severe issues debugging and reprogramming lately, where MCUXpresso/LPC Link V2 failed with the error message "Cannot access core regs when target running" and also Segger a J-Link with Segger's own "Ozone" debugger failed to reprogram the CPU with diverse error messages. Actually, when performing a running reset in Ozone, my program didn't run anymore and when breaking, the PC pointed at a location in the bootloader. Actually, sometimes (but not always), the CPU obviously entered the USB bootloader. However, in my project, the two ISP pins P0.4/ISP_0 and P0.16/ISP_1 are both tied to the supply voltage externally.
So when investigating what happened there, I found that Pin0.4 was still reported low even though it was physically high. At some point I noticed that I erratically activated ADC0_4 (on P0.4) by clearing the according bit in PINENABLE0. When disabling this ADC input again, the pin level was correctly reported as 1 and also the debugging/reprogramming issues disappeared.
Now, while I can understand that the input latch of P0.4 is disabled if ADC0_4 is activated and I'm aware that the switch matrix (PINASSIGN, PINENABLE) is only reset by a power on reset or brown out detection, I found this behavior to be rather surprising. When not even pulling up P0.4 externally during a reset prevents the CPU from entering the boot loader, using e.g. ADC0_4 on ISP_0 doesn't seem to be possible without disabling ISP altogether (through CRP/NO_ISP). I understand that some pin functions like the reset pin need to survive a running reset, but making the ADC input selection reset safe and thus damaging the ISP functionality seems like a strange design choice.
