debug sequences: NXP S32K3xx DFP attach failure

Created from discussion in #1488.

From @dev-apcs:

The snag I have is when using gdb to attach without flashing: the cpu hard-faults.

I tracked this down to vector table corruption - or rather annihilation:

The sample being used moves the vector table to RAM
There's a RAMInitialize sequence in the DFP that, well, clears RAM (under control of the debug variable DoRAMInitialize)
This is all well and good if the core is returned to reset state before running the sequence
With the present implementation, this reset appears not to happen so VTOR is not re-initialised hence the hard fault
Setting DoRAMInitialize to 0 (initially directly in the .pdsc, before I discovered -Opack.debug_sequences.debugvars="DoRAMInitialize=0;") works around the issue.
When I finally RTFM, I notice that some standard reset sequences are not yet supported.

I haven't yet done the analysis to identify the missing sequence but this would appear to be the cause.

I figure that a user script might be the easiest fix for now. Do you have a roadmap for the remaining DFP sequences?

P.S.

I may have spoke too soon. The reset is possibly the responsibility of the client. The CLion run configuration has an option to send a reset command. However, setting this to monitor reset (always) doesn't appear to make a difference.

Start by examining the NXP S32K3xx DFP's RAMInitialize sequence, the DoRAMInitialize debug variable, and the standard reset sequences mentioned in the issue. Reproduce a GDB attach without flashing and determine whether reset restores VTOR before RAM is cleared; done means the attach no longer hard-faults without requiring DoRAMInitialize=0.