I plan to use MCUXpresso with the Teensy 3.6, which has an MK66FX1M0VMD18 microcontroller. Normally it is not possible to connect a debug probe to it, but by resetting the little 16 pin USB loader microcontroller (MKL02Z32VFG4) I understand it can be done. [1] and [2] show how - with Serial Wire Debugging data and clock signals becoming available.
In a thread in this forum [3] it was suggested that the LPC-Link2 [4] could be used with a K66 in the final product. Most of that discussion centered on using the FRDM-K66 which has an inbuilt debug probe, which only works on its own K66.
I guess it would be possible to develop my firmware on a FRDM-K66, with suitable wires to a DIP header which matches the pinout of the Teensy 3.6, and then trust that the resulting hex file (or whatever form the object code could be put in) would work fine when loaded into the Teensy via its USB flash writing arrangements. However . . . the K66 in the FRDM-K66 is a different chip to that in the Teensy 3.6 (2MB flash rather than 1MB), and the Teensy uses two 16MHz and 32.768kHz crystals [5], while the FRDM-K66 uses one 12MHz crystal. In principle the FRDM-K66 could be modified to function like a Teensy 3.6, but the microcontroller is a different model, and I guess I would need to recompile with a different device's headers to generate a valid hex file. These are all complications I would like to avoid.
The list of supported devices at [4] does not include any K66 or similar devices. All those listed are LPC devices. Yet the advice in [3] comes from an NXP technical specialist.
I understand that the LPC-Link2 can be programmed with firmware which makes it behave, to the USB connection, in different ways, including like debug probes from Segger and P&E. However, I think (I have read dozens of web pages today, and I can't remember which one is relevant here) that the firmware from NXP which makes it behave according to CMSIS-DAP (which I only vaguely understand the meaning of), gives it the greatest capabilities. (Those may require access to more K66 pins than purely the debug data and clock pins, such as for tracing, which I know almost nothing about, except that it would be highly valuable.)
I understand that I could use various debug probes which cost (for commercial development) $500 to $2k+, from P&E and Segger. I also understand that I could create my own debug probe with FOS firmware and a Teensy 3.2 [6]. This would work with FOS OpenOCD [7] and so could be used with GDB in general.
Initially I thought I would simply get a debug probe and run it with a GDB server using my favourite IDE (Codelite) on Linux with a cross-compiler and cross-GDB-debugger. Then I learned that a carefully crafted IDE such as MCUXpress would have many advantages when working with these highly complex devices (2,250 page reference manuals etc.), such as generating code to configure the chip, examples, and I think some register display and/or trace capabilities.
So if I could use MCUExpress with the inexpensive LPC-Link2, then this would be great. The IDE and debug probe would both be from NXP and I wouldn't have to integrate disparate systems.
This is a long question for an answer which is probably "No.", but I wanted to outline what I understand so far.
[1] https://mcuoneclipse.com/2017/04/29/modifying-the-teensy-3-5-and-3-6-for-arm-swd-debugging/
[2] https://medium.com/@mattmatic/preparing-teensy-3-6-for-swd-b014b0ce2999
[3] What debugger i-face should I use with FRDM-K66F in MCUXpresso IDE
[4] LPC-Link2|NXP
[5] Teensy and Teensy++ Schematic Diagrams
[6] GitHub - myelin/arduino-cmsis-dap: CMSIS-DAP USB-SWD/JTAG adapter firmware for Pro Micro and Teensy ...
[7] Open On-Chip Debugger
