Good news is at least half of the functionality of the board seems to work. I rigged it to the external debug port of a FRDM-KL25Z board and pyOCD was able to read out the IDCODE and bulk erase flash. The NMI_b (boot mode select) works as expected to force the bootloader to run after the flash is wiped, and RESET causes a USB disconnect on the host when in the bootloader. The only remaining untested bits are the UART and the LED, which need code to be checked out.

Bad news is I didn't research the software end carefully enough.

First mistake: although the tools for flashing in ROM bootloader mode (blhost) are open, they're Windows-only. I'd assumed that there was a Linux version, or that the bootloader (Kibble) talks plain old USB-DFU. Now my to-do list includes a Python reimplementation of blhost, which sounds like a fun project.

Second mistake: Most of the KLxx chips are supported in pyOCD with nearly the same code. This seems to be true for bulk erase. But for some reason I can't flash the target. I don't have time to look into this now, but in-circuit debug support would be nice for development.

Third mistake: I didn't have a binary to run yesterday, and was hoping that the mbed blinky code compiled for the KL25Z with the mbed online IDE would work. However the mbed build server was offline most of yesterday, and I didn't have the cycles to spend on generating a binary with alternate tools (and the right target). Yeah, TANSTAAFL and all. I also have serious doubts that the KL25Z build will work anyway due to the TBD's use of the internal oscillator, so it might be for the best.

At this point I'm happy that I haven't run into problems that point to board or reflow screwups.