How to program a blank MKL02 bootloader chip for a custom MK20DX256 board? No USB response on my new board

joexzl

New member
Hello PJRC team,

I am working on a new custom board based on MK20DX256VLH7 with an MKL02 bootloader chip, following a Teensy-style design.

At the moment, when I connect the board to USB, there is no response at all on the PC side. Nothing appears in Device Manager, and I do not see any meaningful USB activity.
I am now trying to confirm whether this could be caused by the MKL02 chip being blank / not pre-programmed.
My questions are:
  1. Can a blank MKL02 be programmed with the Teensy bootloader by the user?
  2. If yes, what is the official method, required hardware, and software toolchain to do that?
  3. If no, does that mean a custom board like this must use a PJRC pre-programmed MKL02 in order to work with the Teensy ecosystem?
  4. Would a blank MKL02 alone be enough to explain why the board shows no USB response at all?

For reference, my current setup is:

  • Main MCU: MK20DX256VLH7
  • Bootloader chip: MKL02
  • External crystal: 16 MHz passive crystal
  • Symptom: no USB enumeration / no device detected by PC

I am also checking the hardware side, including clock startup and connections, but I would like to first confirm whether the blank MKL02 itself would already prevent the board from showing any USB / bootloader behavior.

Any guidance would be greatly appreciated.

Thank you.
 
does that mean a custom board like this must use a PJRC pre-programmed MKL02 in order to work with the Teensy ecosystem?

Yes, confirm, you do need to get the programmed chip from PJRC.

There are 2 different versions, one for Teensy 3.x and the other for Teensy 4.x compatibility. Since you're using a MK20 chip, be careful to buy the with Teensy 3.x compatibility.


Would a blank MKL02 alone be enough to explain why the board shows no USB response at all?

Yes, no USB communication is exactly the expected behavior when both chips are blank.

If you need a further confirmation, you can measure the Reset signal voltage. A DC voltmeter should show a low but not exactly zero voltage, probably in the range 0.15 to 0.3 volts, but the exact voltage you see can vary. If you use an oscilloscope or logic analyzer to view the signal, you'll see it's really a rapidly pulsing waveform, not a DC voltage at all. It spends most of the time low at zero volts, then goes high briefly, and this cycle repeats infinitely. Any multimeter set to DC voltage will show you the average, which is why you'll measure a low but not zero DC voltage.

Two features of the MK20 chip create this pulsing waveform. The Reset signal is bi-directional. If the MK20 performs a warm reboot, it pulls the Reset signal low. The other feature is the watchdog timer, which is enabled by default in MK20 with a fairly short timeout. When the memory is blank, the very first attempt to execute any instruction causes a memory fault because the blank memory isn't a valid address in the reset vector, which then causes another "hard fault" when the ARM CPU tries to vector to the fault handler. So the ARM CPU immediately goes into a special stop mode. Then a short time later, the watchdog timer causes a warm reboot. The result is that pulsing waveform on the Reset pin, and of course no USB communication can possibly occur!

That's the long explanation. The short version is yes, you really do need the programmed MKL02 chip.
 
Thank you, Paul and BriComp, for the clarification.

After further checking, I can confirm that the issue was indeed caused by the MKL02 chip being blank and not pre-programmed. That also explains why the board showed no USB response at all.

I have one more question:
Is there an official distributor or reseller in mainland China, or Taiwan where I can buy the pre-programmed MKL02 chip?
If not, is it possible to order these chips directly from PJRC for small-volume or bulk purchase?
Thanks again.
 
Back
Top