The bootloader product page (https://www.pjrc.com/store/ic_mkl02.html) says:
> By using this chip and a blank MKL26Z64VFT4 or MK20DX256VLH7 or MK64FX512VMD12 or MK66FX1M0VMD18 ... or MK64FX512VLQ12 or MK66FX1M0VLQ18 ... the MKL02 or MKL04 will automatically detect which chip you've used and implement either Teensy LC, 3.2, 3.5 or 3.6.
In what way is that automagical chip detection performed?
The reference manual (https://www.nxp.com/docs/en/reference-manual/KL26P121M48SF4RM.pdf) gives two ways to detect which chip you're using: one is the SWD identification register MDM-AP IRD/0x0100_00FC, which is 0x001C_0020 for all KL26 chips. This is what I hope the bootloader chip is using, and it seems logical because it's talking over SWD. For another example, this register is 0x001C_0000 on the MK20DX256VLH7 and other parts in that family, should be enough to distinguish between Teensies.
The chip could also be more strict, using some components of the System Device Identification Register, SIM_SDID/0x4004_8024, which has the value 0x4614_**04 for the MKL26Z64VFT4 (which has 8 KB of SRAM) or has the value 0x4615_**04 for the MKL26Z128VFT4 (which has 16 KB of SRAM). Different pinouts also have different values, different revision levels and silicon die revisions change the nibbles marked **. The MK20 has a completely different layout for this register. It is #defined in cores/teensy3/kinetis.h, and that constant is not used in the Arduino source, but I imagine if it was used it would be in the closed-source code for the MKL02.
More to the point, if I modify boards.txt to add a teensyLC128, compile for build.mcu=mkl26z128, build.flags.defs=-D__MKL26Z128__, add a mkl26z128.ld linker script, and touch up all the #ifdef(__MKL26Z64__) in arduino/hardware/teensy/*.[ch], will the MKL02 flash an MKL26Z128VFT4 chip?
One follow-up question, assuming the former can be made to work - does the MKL26 target chip need to communicate with the MKL02 on every power-on reset, or can I put a weak pull-up on my reset line, have one of these special bootloader chips in a bed-of-nails tester on the production line, use it to flash my hex file once to each board, and not have to solder the bootloader chip to every PCB that's produced? I understand that I would be unable to reflash it in the field over USB if I didn't connect it.
> By using this chip and a blank MKL26Z64VFT4 or MK20DX256VLH7 or MK64FX512VMD12 or MK66FX1M0VMD18 ... or MK64FX512VLQ12 or MK66FX1M0VLQ18 ... the MKL02 or MKL04 will automatically detect which chip you've used and implement either Teensy LC, 3.2, 3.5 or 3.6.
In what way is that automagical chip detection performed?
The reference manual (https://www.nxp.com/docs/en/reference-manual/KL26P121M48SF4RM.pdf) gives two ways to detect which chip you're using: one is the SWD identification register MDM-AP IRD/0x0100_00FC, which is 0x001C_0020 for all KL26 chips. This is what I hope the bootloader chip is using, and it seems logical because it's talking over SWD. For another example, this register is 0x001C_0000 on the MK20DX256VLH7 and other parts in that family, should be enough to distinguish between Teensies.
The chip could also be more strict, using some components of the System Device Identification Register, SIM_SDID/0x4004_8024, which has the value 0x4614_**04 for the MKL26Z64VFT4 (which has 8 KB of SRAM) or has the value 0x4615_**04 for the MKL26Z128VFT4 (which has 16 KB of SRAM). Different pinouts also have different values, different revision levels and silicon die revisions change the nibbles marked **. The MK20 has a completely different layout for this register. It is #defined in cores/teensy3/kinetis.h, and that constant is not used in the Arduino source, but I imagine if it was used it would be in the closed-source code for the MKL02.
More to the point, if I modify boards.txt to add a teensyLC128, compile for build.mcu=mkl26z128, build.flags.defs=-D__MKL26Z128__, add a mkl26z128.ld linker script, and touch up all the #ifdef(__MKL26Z64__) in arduino/hardware/teensy/*.[ch], will the MKL02 flash an MKL26Z128VFT4 chip?
One follow-up question, assuming the former can be made to work - does the MKL26 target chip need to communicate with the MKL02 on every power-on reset, or can I put a weak pull-up on my reset line, have one of these special bootloader chips in a bed-of-nails tester on the production line, use it to flash my hex file once to each board, and not have to solder the bootloader chip to every PCB that's produced? I understand that I would be unable to reflash it in the field over USB if I didn't connect it.