Custom build Teensy 3.1 PCB not responding

Not open for further replies.


Active member
Hi all,

I have created my own Teensy 3.1 PCB, but it does not respond as expected (i.e. no USB-Serial-Connection entered in the Teensyduino IDE). Connecting a standard Teensy 3.1 works.

I have read the other threads. I did not connect VOUT33 initially as I am using an external Power Supply circuit (Lipo charger and Voltage regulator). After reading a few posts here I soldered a cable from VOUT33 to 3V3. The other posts aren't clear about wether I should connect VREGIN to VCC too. I tried both ways (i.e. letting VREGIN floating and currently it is connected to 3V3). 3V3 is the output from my voltage regulator.


I have a bit of noise on the 3V3 line, but I am not quite sure if this is heavy noise or if it's ok. I have attached an image showing it.

As described in other threads at started RESET and PROG-Lines of the Minitan54 are supposed to be high, I noticed that RESET is low, goes high every 50us and then goes low again. Paul already described this to be correct. Pressing the PROG-Button (pulling it LOW) does pull RESET to low too, so that is correct too I think.

In this image you can see the RESET-Line going low while pressing the button, then there are a few LOW pieces, followed by the LOW-HIGH-LOW pulses every 50us. I have also attached a detailed shot of these Pulses:


When RESET is low the Minitan54 will program the MK20, so there will be data transfer. This is what I read in another thread. And this is what I get. I am not quite sure if the pin assignment in the images is correct, but these are the signals from PTA0 and PTA3. They look like clock and data. Are they too noisy?

This is PTA3:

And PTA0:

(as said before it could be the other way round, but I doubled checked that my connections are the same as in the Teensy Schematic).

Next the MK20 should bring up the crystal. But it doesn't. I am using a 8pF 16 MHZ crystal, I have a ground plane. And the tracks are as short as possible (so very, very close).

I don't really know what to do next. Could it be the crystal? Or is there another problem? Anything I can check?

Thanks very much for your help.

Whatever the problem ultimately turns out to be, I'd like to ask you to please post a followup when it's found and confirmed fixed. As you've already seen, building a list of problems and solutions others have faced and solved is incredibly helpful. Please do let us know when it's fixed and what turned out to be the cause, so others who come later can also benefit.

From everything you've described, except the crystal, it sounds like you board is very close to working. Those signals all look pretty reasonable.

The crystal is only supposed to run when the MK20 is running the bootloader, or when your own program runs. It doesn't start automatically oscillating, like on AVR. It only oscillates when software tells it to do so. With the USB cable disconnected, after you've pressed the button, the crystal should definitely start oscillating.

Measuring the crystal signal is tricky. A 10X probe on most oscilloscopes will add about 10 pF or more loading, which is almost enough to stop it from oscillating. A 1X probe or multimeter or almost anything else can cause it to stop. So when checking the crystal, it's important to make sure your measurement isn't causing the problem. Testing your measurement on a known-good Teensy 3.1 is a good way to verify it doesn't stop the crystal. Also pay attention to how close you connect the probe's ground clip, since that can also play a role. The last thing you want is to believe your probe and scope are good because it measured a Teensy 3.1 crystal, but then stops your crystal because you clip the ground lead a few inches away.

If the crystal actually is starting up, check the USB signals. In this message only yesterday, a board was nearly working as yours, but it wasn't responding at all to Teensy Loader because the D+ signal was connected to the D- pin on the USB connector, and vise-versa. Swapping the signals got it talking to the Teensy Loader.

thanks for your help. I just don't know what to check. Bringing up the Crystal. What does that mean? Do I see a voltage on both pins? On Teensy I see a sinus type waveform on the crystal pins. If my board would start the Crystal I would see it I think. My GND of the Probe is about the same length away as on the Teensy. Measuring my Crystal Pin just does not show anything, like probing GND. Nothing, all the time, so I don't think the MK20 tries to bring up the Crystal?

How can I check that the MK20 is working, received the code, is doing something? The Crystal is brought up by software. But how can I check that there is any software running on the MK20?

I checked noise on the 3V3 line of one of my Teensys and it's about the same as my signal.

Bildschirmfoto 2015-02-05 um 14.31.11.jpgBildschirmfoto 2015-02-05 um 14.30.58.jpg

I have attached the PCB Layout around the Crystal and MK20 and Minitan and the Schematics of this section. I can see signals, but I don't know if they are good enough and/or the MK20 is starting.

I don't want to build another board if they are chances to further narrow the issue, because all of the components are quite expensive and hard to get in Germany. So wasting another board does not make sense for me at the moment.

I think it would also be helpful (for others with similar issues too I think) if there would be some documentation what to expect from the signals - like the Power Up Sequence in Datasheets. This way we could narrow down issues. I.e. someone in the forums said, that PT0-PT3 is used for data transfer, I cannot see anything happen on PT1 and PT2.

Thanks for your help.
Last edited:

I did not want to give up and I have built my board again. This time I just soldered the Teensy Components and served 3,3V by using my Lab-Power-Supply and soldering 3.3V and GND to the board at appropriate test points. The board came up with RESET-Signal going low by pressing the PROG-Button, it came HIGH and I saw the crystal working.


But USB did not work. I soldered connection from PIN VOUT33 to 3.3V as this seems to be necessary for USB to work. Next try. This time I saw activity on the USB_D+ and D- lines as I see it on the Teesny. The Teesny Loader found the board. But I am not sure if I really got code on the MK20?

This is the verbose log:
22:47:10: Teensy Loader 1.20, begin program
22:47:10: File "Ampel.cpp.hex". 10932 bytes, 4% used
22:47:10: Listening for remote control on port 3149
22:47:10: initialized, showing main window
22:47:10: HID/macos: no devices found
12:15:34: Device came online, code_size = 262144
12:15:34: Board is: Teensy 3.1 (MK20DX256), version 1.03
12:15:34: File "Ampel.cpp.hex". 10932 bytes, 4% used
12:15:34: HID/macos: status: ok
12:16:45: remote connection opened
12:16:45: remote cmd: "comment: Teensyduino 1.20 - MACOSX"
12:16:45: remote cmd: "dir:/var/folders/nk/vfgb_cxj01g5kqf77qp5y06h0000gn/T/build5638971547806682850.tmp/"
12:16:45: remote cmd: "file:Ampel.cpp.hex"
12:16:45: File "Ampel.cpp.hex". 10932 bytes, 4% used
12:16:45: remote cmd: "status"
12:16:45: status data sent
12:16:45: remote cmd: "auto:eek:n"
12:16:45: File "Ampel.cpp.hex". 10932 bytes, 4% used
12:16:45: elf size appears to be 262144
12:16:45: elf binary data matches hex file
12:16:45: Code size from .elf file = 262144
12:16:45: begin operation
12:16:45: remote connection closed
12:16:45: flash, block=0, bs=1024, auto=1
12:16:45: flash, block=1, bs=1024, auto=1
12:16:45: flash, block=2, bs=1024, auto=1
12:16:45: flash, block=3, bs=1024, auto=1
12:16:46: remote connection opened
12:16:46: flash, block=4, bs=1024, auto=1
12:16:46: remote cmd: "status"
12:16:46: status data sent
12:16:46: flash, block=5, bs=1024, auto=1
12:16:46: remote connection closed
12:16:46: flash, block=6, bs=1024, auto=1
12:16:48: program: write error
12:16:48: end operation
12:16:48: redraw timer set, image 11 to show for 4000 ms
12:16:51: Auto Button event
12:16:51: Auto mode: enabled
12:16:51: File "Ampel.cpp.hex". 10932 bytes, 4% used
12:16:51: elf size appears to be 262144
12:16:51: elf binary data matches hex file
12:16:51: Code size from .elf file = 262144
12:16:51: begin operation
12:16:51: flash, block=0, bs=1024, auto=1
12:16:53: program: write error
12:16:53: end operation
12:16:53: redraw timer set, image 11 to show for 4000 ms
12:16:56: Reboot event
12:16:56: begin operation
12:16:56: sending reboot
12:16:59: begin wait_until_offline
12:17:01: offline failed, timeout after 50
12:17:01: reboot error
12:17:01: end operation
12:17:01: redraw timer set, image 13 to show for 4000 ms
12:17:05: redraw, image 10
12:17:20: Reboot event
12:17:20: begin operation
12:17:20: sending reboot
12:17:22: begin wait_until_offline
12:17:25: offline failed, timeout after 50
12:17:25: reboot error
12:17:25: end operation
12:17:25: redraw timer set, image 13 to show for 4000 ms
12:17:29: redraw, image 10
12:17:34: Device went offline
12:17:34: HID/macos: number of devices found = 0
12:17:34: HID/macos: no devices found (empty set)
12:25:39: Auto Button event
12:25:39: Auto mode: enabled
12:25:40: Auto Button event
12:25:40: Auto mode: disabled
12:46:27: Verbose Info event

I did not really pay a lot of attention to the USB-Tracks as I should after reading about it. I think I saw some reflections on the scope, although I am not quite sure.

But I cannot further test, as the board now does not come up again. Reset is oscillating with the small HIGH peaks, pressing the Button pulls RESET low, data is transferred on PT0 and PT3 (as with the first board), but then RESET stays LOW. But RESET should be HIGH.


Any idea why the board suddenly stopped working ans RESET is LOW. Did Teensy Loader upload code which now prevents the MK20 to run the Bootloader-Code?

Thanks in advance,
another thought, what are you doing with D33/PTA4. I see it's connected to something in your schematic. In older versions of Teensyduino, this pin has to be high/floating (not low) during startup. I'm not sure if it's fixed in the current Tennsyduino.
Thanks for taking time to help. I have connected PTA4 to a signal called CHARGEALERT from an IC which measures the battery lifetime (Battery Management IC, MPN: MAX17043G+U). It's active low and is pulled up with a 10k resistor. In my first (fully assembled board) I will give that a try to measure the signal during startup, but I am quite sure it's HIGH. In my second board - which has been working for a few startups and then stopped to work I did not assemble the IC. This line is floating as I also did not assemble the pull up resistor.

I don't understand why the RESET line does not come HIGH. As I understand it the Minitan has control over the RESET pin. It takes it low during programming and takes it HIGH to start the MK20, right? Therefore the MK20 does not bring RESET HIGH? Why?

Thank you very much for your help.
Yes, VOUT has to be connected to 3.3V for USB to work. Other forum members have recommended running 3.3V into VREGIN as well to let the internal MK20 voltage regulator simply drop out while also not having a bad hair day on account of its Vout being higher than the VIN (if VREGIN were left floating).
Thanks Constantin for hinting the VREGIN pin. I have soldered VREGIN to 3.3V, but that does not make a difference. In another thread someone found out, that VBAT has to be connected also for the RTC clock to work. I also soldered a wire to VBAT. That does not make any difference too. The board stays the same all the time. RESET stays LOW after the Minitan has sent the code.

Perhaps I killed something by pointing my scopes probe somewhere?
This may be a silly question, but did you get more than 1 copy of your custom board made?

Yes. I have received 3 (OSH Park). I have built one with all components and two boards with just the Teensy Components and two wires soldered to 3.3V and GND and to my Lab Power Supply.

The fully built board never worked (Crystal not starting and RESET keeps oscillating after being pulled low for programming a second or so).

The first bare bones board worked (Crystal working but no USB), but suddenly the MK20 smoked and got very hot. I think I pointed my probe between 3.3V and GND pins of MK20 left of the USB pins. I remember probing the USB pins and suddenly the current digits on my Lab Supply went from 0.02 to 1.9 and my MK20 left this world ;-).

After that I built the third board with just the teensy components to the point that it got recognized by the teensy loader. After that I did not get it up and running again and the Crystal does not start anymore, the RESET line stays low but I think the MK20 is alive as it shows the oscillating RESET line until I press the button which pulls PROG and RESET low. But as said before RESET does not come HIGH again.
Last edited:
Many "dead" reports sound alike.

Can you desolder the MK20 from the last board (the only one that ever responded) and try a new chip? If something did go very wrong with the MK20 setup, and the Mini54 is still responding to the pushbutton, replacing the MK20 chip should let you recover.
I have no MK20 left. I installed 3 of them and I don't have anymore. MK20 is hard to get in Germany, as my favorite Distributor does not sale them in Germany - don't know why, because of encryption features or some other laws permitting it.

As said before the first - fully assembled - board did not work. I have posted an image of the Noise-Level I get from the voltage regulator I have installed on my board and it's quite noisy. I found out that I did make a mistake in my PCB-Layout. The voltage regulator needs two ground nets that are connected at one single point on the PCB. Well, I just did not do that. So the feedback pin got very noisy values resulting in noisy output. I soldered a cable to fix that and the output got better, but perhaps not good enough. I am working on this.

The other two boards were driven by my lab power supply with 3.3V directly by soldering cable on the PCB and leaving out the VREG section on the PCB. This way I got both boards to respond. I saw some issues (ghosting) on the USB-lines and the Upload did not work. After that the board stopped working.

Today I did some prototyping on another project and recognized a voltage peak in my power supply. I have attached a shot of the scope in roll mode. Turning the power supply on immediately and without any up and downs delivers 3.3V. But turning it off is followed by slowly falling voltage, followed by a very sudden voltage peak of around 30V !! As I have wired the cables to the PCB, without a switch, I used the Power Supply On/Off Button to turn the PCB on and off. I did measure for a voltage peak when turning it on before I attached the PCB which was fine, I did not test turning it off.

I think turning the PCB off after the first successful try killed the MK20, the Minitan or both by delivering 30V - even for a short period.

Is this typical behavior of a lab power supply or is my supply just crap? Is such a voltage peak enough to kill the MCUs? Or could just be one of the surrounding components (Caps, Resistors) be damaged. The MK20 still shows the 56us RESET-Signal, the MK20 still draws RESET to LOW when pressing the Button, but RESET stays LOW as said before.


I am happy to have found a possible explanation of why the board first worked and then suddenly failed. I would be very interested in your experiences and opinions if this is really a good explanation.

The PCB shows a larger number of issues, the voltage regulator is too noisy, the USB-line does not have the 90 Ohm impedance and I did not match tracks (they are about 100 mm long) and I installed the terminating D+,D- resistors in the middle of the line and not at the USB-connector where it should (as I have learned now). This might be the reason why teesnyloader did fail when uploading the data.

I will have to make a new revision of my PCB, but before doing that I really would welcome your opinions if my power supply could have killed my MCUs.

Wow, I wish I saw your schematic earlier.

I'm using the same MINI54 as you but have not placed a Ground for pin 5 (analog ground) nor a 1uf cap for LDO_CAP pin 18...

Looks like I might need to do a little jumper here and there if needed. I'm not using the analog part at all.. No idea if it is important.

Boards will come in blank, so I can add stuff as I'm placing components.

Wish they would of just let me buy the Teensy 3.1's..
I think turning the PCB off after the first successful try killed the MK20, the Minitan or both by delivering 30V - even for a short period.

When I read through your post I was expecting the peak to be only for a few ms tops, but it seems you exceed the specs of the mk20 voltage wise for ~300ms or more (guesstimate). That's quite a long time so I should imagine it's quite possible to have killed voltage sensitive IC's. I've no idea how resilient the chips are though.

What model is the bench PSU? It certainly shouldn't be doing that, at least in my experience. Bench power supplies that blow up what you're trying to test aren't particularly useful. ;P
My PSU is this one: It's cheap crap, but I did not expect it to be so bad. I am already googling around for a better one as you say it: That's not very useful. It's always the same: Buying cheap is buying twice :-(.

I did another test a minute ago: This time the PSU has been "cold" for a few hours. As you can see the voltage is for nearly two seconds above 3.3V. That's just insane. Thanks for pointing out the specs of the MK20.

Any recommendations on a good PSU? I don't need fancy features, it should not cost a ton (I blowed MCUs for $50 so I am willing to pay $200 if necessary) and should deliver reliable results.

Thanks for all your help.

I can't say that I'm an expert in this field; I'm a simple third year Digital Systems Engineering student aha. The PSU I have sitting here on my bench is a low-cost Tenma unit; but I've found it perfectly reliable and stable enough thus far anyway. As you say though, quality is directly proportional to price though, so spending good money on decent PSU would probably be worthwhile in the long run.

As for exactly who to spend that money with though, I can't help I'm afraid.

I'd be thinking that its' more likely your power supply is faulty though, with issues like that, as opposed to just being poor quality. Of course poor quality is likely to lead to more faults however.
Is it in warranty at all? It certainly shouldn't be doing that.

(EDIT: The above is a valid point; are you readings on the oscilloscope with load?)
I may be biased because I work at a company that builds test equipment (including supplies), but, in my opinion, no bench supply should ever do that, ever. With or without load.

There's either something broken in the supply, or it's a terrible design.

With a switching supply, the inductor can generate really high voltages if you try to shut off the current too fast, but that should never, ever be coupled to the supply output.

I'd return it to the supplier if you can and see if you can get one that doesn't have a voltage spike.
So basically I followed the same schematic for my project.
I had issues so I replaced the mini54 and the MK20 (MK20 a few times because of bent pins and frustrations).

I had used inductors instead of ferrite beads.. Will change them out.

So I was reading about the Teensy how it works and that the blink program is always sent out on the boards.

So sitting here, I decide to load the blink program. No LEDs, but just to check something..
Upload to the board (I have 2 circuits, working with one to test) and the Press Button to Activate.
I did and the blue bar filled and said reboot ok. Then the USB added the board to USB commport.

I worked on this 1/2 a day and part this morning. Wow, it was probably ok yesterday.. Oh well.. Onward to the rest of the board..
I promised to post if I were able to make some progress. Well I did :). As posted earlier I had some trouble getting my custom teensy to work. As I found out later my power lab supply killed my MCUs. I have trashed my old PSU and bought a new one. As I had a few issues with my PCB I did another revision that fixed the bugs I knew till then and ordered a new batch at OSH park.

My device is running with a LIPO-battery. I designed a circuit based on Sparkfuns Powercell Breakout board. It features a 3.3V voltage regular (buck and step-down) and a LIPO charger. In my previous board I had some issues with bad PCB-layout in this part which caused high noise. So I redesigned the whole area, but the components are the same.

As I am using my own voltage regulator I had VOUT, and VREGIN floating and just connected the VDD pins to my own 3.3V net. But you have to connect VREGIN and VOUT as these pins power important parts of the MK20!

I did not really took care with the USB part. I had the terminating resistors (33 Ohm in the schematic) in the middle of the track (length) and not at the beginning of the connector. I also did not really take care of impedance and routing with the same length. My design ist quite long and the USB-track is around 3 inches (8cm) long. I redesigned the whole USB part and changed to a 4 layer PCB. I used a differential pair impedance calculator and used EAGLEs differential pair routing to get the impedance right and used the meander function to equal the track length.

Coming from Arduino I did not really got it, but Teensy is a quite complex product. High speed design guidelines should be taken care of when creating your own Teensy based PCB. I have found a very, very good document that really explains these guidelines:

Take a look at what trade has to offer. They have a lot of very interesting products but also a lot of very useful documentation.

I have fixed these issues:

- I connected VREGIN to 3.3V
- I connected VOUT to 3.3V
- I connected VBAT to my LIPO Battery (to keep the RTC-part running) but added a jumper to set it to 3.3V or a coin cell. Using the LIPO battery works so far but I did not test the RTC part
- Redesigned the USB+ and USB- tracks and switched to a 4 layer PCB to get the USB differential pair impedance right
- The MK20 has three VDD pins. In my previous design I did not add 0.1 uF capacitors to each of them. In my new design I made sure that every power pin has "its own" (meaning very closely placed) 0.1 capacitor.
- I added a few jumpers to be able to reroute the VDD parts. In my previous design I had to wire a lot of very short cables to very small pins in order to reroute or try other connections. I did not really need them, but it's good to know they are there.
- I added a SWD port. Pauls MCU uses the SWD protocol to program the boot loader to the MK20 each time you press the PROG Button. I exposed these pins SWD pins and used a PFET to cut of power to the MiniTan as soon as a SWD programmer is attached to this port (the SWD programmer delivers 5V so I used that to cut of the power rail to the Minitan). I did not try that as this just should be a fallback method of programming the MK20 if the teensy part would fail (again). But it didn't. This port is very useful as it exposes the PTA1 and PTA3 pins. I could immediately see that the Minitan and MK20 are working correctly on my scope.

I will write a blog post in the next week as a guide on how I did successfully bring up my own custom teensy and will post a link.

There are a few minor issues left with my decive. The voltage regulator often regulates to 1.1V instead of 3.3V. Playing around with the USB connector brings it up to 3.3V sometimes. I don't know what's wrong here. And not all components are soldered on the PCB. I will let you know when I make progress.

But if the voltage regulator delivers 3.3V everything works fine. I can program my board using the teensy loader and everything is working fine so far.

One last comment: Bringing up brand new hardware can be hard. You can read that everywhere. And they are right. Soldering a board for hours, testing it with your multimeter for shorts and other stuff, plugging in the USB cable and it does nothing. That is so frustrating. And you really don't know why it's not working. Is it the schematics, the board, a manufacturing error in your PCB or is it just not soldered correctly.

It took a few days to get my board up and running. And the reason: Bad soldering! The voltage regulator is a QFP design. You don't see the pins. I used solder paste and my Hot air gun to solder it. But it just did not make connection. After desoldering it with the hot air gun and resoldering it everything worked fine.

I ordered a toaster oven from Beta Layout (Dave from EEVblog had great success with it) to get past these issues with the next board. I know there can be problems too, but I think that should be more reliable as my place a hot air gun on the device and pray method ;-).

After having a few very frustrating weeks I am very, very happy now. All of you have been very helpful and I will give that back with a blog post explaining the most important things to consider when creating your own board. I will post a link as soon as it is online.


Last edited:
Thanks for such a detailed write up. All noted for when I eventually come to rolling my own Teensy based boards. =)
As promised before I have written a rather lengthy blog post about my learnings building (successfully) a custom Teensy board:

You will find PCB layouts, USB design considerations and the values and solutions I came up with, a few information on used parts (as the original Teensy schematic is not very specific here) and a guideline about how to bring up your own board and what to expect from each signal. That should hopefully help a lot if you have problems getting your own board up and running or if you are considering building your own.

Have fun.


@Paul: Perhaps you can place a link on your Mini54Tan page. Thanks in advance.
Due to popular demand I have created a simple "reference board" for a custom Teensy 3.1 in EAGLE CAD format. This contains board layout, schematics and BOM (all parts contain an attribute MPN with the part number). This layout and schematics have been working for me (see posts above) flawlessly and should get you up and running very quickly. Please note that you need an EAGLE License as this example is a 4-layer board.

You can find the documents at our Github repository here:
Hey that's awesome!

My work still hasn't let me do this (waiting for approval to publish....) and my only comment is that the two lines going from the bootloader to the I2C headers on the MK20 are not needed. Simplifies things somewhat and takes 3 seconds to do. The 5x5mm QFN bootloader chip also needs fewer capacitors, is smaller, and requires no via transitions to be implemented. Helps on a more common 2-layer board!

Hope you are well and thank you for contributing this and your other musings on app fruit. I hope you participate in the wiki when the time comes because you have made some really good observations on your blog. Cheers, Constantin
Not open for further replies.