DatoDavid
Member
First of all a big thank you to Paul et al. for conceiving and making the Teensy hardware and software.
I designed and built a custom board with a MK02 bootloader carefully unsoldered from a Teensy LC and a fresh MK20DX256VLH7. It's a main board for a synthesizer, with MIDI in and outputs, headphone/speaker amplifier and connectors that go to the potentiometers/leds. Unfortunately, the Teensy part is not working.
Here is part of the schematic, which looks a lot like the Teensy 3.2 schematic found on https://www.pjrc.com/teensy/schematic.html
I've left out the LDO, amps, connectors and MIDI stuff.
It's not responding to a programming request and I can't seem to figure out why. The K20 keeps resetting every few microseconds, which is expected behaviour for an unprogrammed chip, but it doesn't seem to take in the bootloader code.
First suspect is the crystal:
It's a surface mount HC49 16MHz 18pF crystal with two 20pF load capacitors. The bottom layer is an unbroken ground plane with no switching traces near the crystal. It's probably not as neat a layout as the four-layer Teensy with its small SMD crystal, but it should be okay. I can't measure any oscillations, so the microcontroller is obviously not starting up the crystal.
I've built four of these boards and all seem to suffer the same issue. In a very radical move, I programmed a blink sketch onto a working Teensy 3.2 and transplanted the working microcontroller onto my board. Surprisingly, it worked. The crystal oscillates nicely at 16MHz and the blink pin is happily blinking away. To me, this means we can rule out the crystal as a source of the problem.
Other things I've done:
- Add extra decoupling to the 3V3 line. It's rock solid if I look at it with the scope
- Unconnect the signals to PTA4, so that the uC doesn't accidently end up in EZport mode
- Checked the polarity of the USB D+/D- signals
- Checked Vbat and Vregout
Here is a logic analyzer grab of what is happening on the SWD/JTAG pins between the MK02 and MK20:
You can clearly see the repeating resets. Shouldn't the MK02 pull reset HIGH? To me the TCK signal looks quite erratic for a clock signal. The MK02 keeps sending signals even if I don't press the PROG button.
Any ideas on how to hunt down this issue?
I have a scope and logic analyzer, so if there is data I need to measure/grab I can do so. Also, I have a NXP/Freescale FRDM board that I can use as an OpenSDA JTAG/SWD programmer, except that I don't know how to use them.
I designed and built a custom board with a MK02 bootloader carefully unsoldered from a Teensy LC and a fresh MK20DX256VLH7. It's a main board for a synthesizer, with MIDI in and outputs, headphone/speaker amplifier and connectors that go to the potentiometers/leds. Unfortunately, the Teensy part is not working.
Here is part of the schematic, which looks a lot like the Teensy 3.2 schematic found on https://www.pjrc.com/teensy/schematic.html
I've left out the LDO, amps, connectors and MIDI stuff.
It's not responding to a programming request and I can't seem to figure out why. The K20 keeps resetting every few microseconds, which is expected behaviour for an unprogrammed chip, but it doesn't seem to take in the bootloader code.
First suspect is the crystal:
It's a surface mount HC49 16MHz 18pF crystal with two 20pF load capacitors. The bottom layer is an unbroken ground plane with no switching traces near the crystal. It's probably not as neat a layout as the four-layer Teensy with its small SMD crystal, but it should be okay. I can't measure any oscillations, so the microcontroller is obviously not starting up the crystal.
I've built four of these boards and all seem to suffer the same issue. In a very radical move, I programmed a blink sketch onto a working Teensy 3.2 and transplanted the working microcontroller onto my board. Surprisingly, it worked. The crystal oscillates nicely at 16MHz and the blink pin is happily blinking away. To me, this means we can rule out the crystal as a source of the problem.
Other things I've done:
- Add extra decoupling to the 3V3 line. It's rock solid if I look at it with the scope
- Unconnect the signals to PTA4, so that the uC doesn't accidently end up in EZport mode
- Checked the polarity of the USB D+/D- signals
- Checked Vbat and Vregout
Here is a logic analyzer grab of what is happening on the SWD/JTAG pins between the MK02 and MK20:
You can clearly see the repeating resets. Shouldn't the MK02 pull reset HIGH? To me the TCK signal looks quite erratic for a clock signal. The MK02 keeps sending signals even if I don't press the PROG button.
Any ideas on how to hunt down this issue?
I have a scope and logic analyzer, so if there is data I need to measure/grab I can do so. Also, I have a NXP/Freescale FRDM board that I can use as an OpenSDA JTAG/SWD programmer, except that I don't know how to use them.