Forum Rule: Always post complete source code & details to reproduce any issue!
Custom PCB - Teensy 3.1 with Audio board - won't boot up
Please look at the following schematics and let me know if I did something wrong. I bought MINILAN54 chips for 6 demo boards, had the factory solder everything up, and now I can not get the first test PCB to show up as a USB device or comm port like normal. Breadboard version with Teensy 3.1 works great of course. Powering with 5V and 3.3V linear regulators and LiPo 7.4V. Any ideas?
Note schematic out of date: bootloader chip P3.2 actually connects to RESET_B, not RESET to RESET_B as shown
PCB basic parts:
- MK20DX256 and MINILAN54 (teensy 3.1 and bootloader)
- SGTL5000 and microSD card (teensy 3.1 audio board)
- amplifier circuit
- USB port
- 2 bluetooth chips
- several GPI pins blanked out, should be irrelevant
Wrong crystal oscillator CSTCE16MOV53-R0
--Crystal is close by and has only ground plane directly under, no traces too close.
Incorrect schematic for VREFL, VSSA, VREFH, VDDA, VREF_OUT ???? I'm not using analog reference, but am planning to use analog pin inputs later...
VREGIN tied to 3.3V rail???
MINI54LAN did not come programmed properly?
Incorrect Audio circuit? I only use left channel audio out, no microphone input needed
No resistors on USB datapins
USB 5V not used, should not matter right?
Last edited by zachtos; 01-14-2015 at 02:04 PM.
Reason: schematic is out of date
I'm not positive, but here's a quick place to check. Because the crystal that you've chosen has built in capacitors, and the normal teensy crystal does not, you'll probably need to edit these lines in mk20dx128.c:
These lines set up internal shunt caps in the mk20 chip itself, but with the caps built into the crystal you bought, you probably don't want any internal shunt caps at all. You may be able to just comment that line out, otherwise you'll need to look a little closer at the multipurpose clock generator chapter in the reference manual.
// enable capacitors for crystal
OSC0_CR = OSC_SC8P | OSC_SC2P;
There's a thread where someone else's custom teensy board was fixed with a similar solution, but I can't find it at the moment.
Originally Posted by whollender
Thanks, I will check this, but at the moment, the PCB does not show up as a device for me to program, so I really am not able to put code on it without that working first (as a comm port)
I guess, even if the board layout looks correct, would be nice to hear that to rule out schematic. Otherwise, what should normally happen when I plug in a fresh micro w/ new bootloader chip? Just show up as a USB device just like a normal Teensy?
As far as I know, it should look like a regular teensy because the MINI54 chip comes pre-loaded with the bootloader from Paul.
I looked a little bit closer at your schematic, and it looks like the reset line may be the problem. The Teensy schematic, and list of required MINI54 connections say that the MK20 chips reset pin (pin 34) should be connected to the MINI54 chips P3.2 pin (pin 6 for QFN, 8 for TQFP), not it's reset pin. The Teensy 3.x schematic has the MINI54 chip's reset pin left open.
TL;DR = The MK20 crashes, because it has no code, and press the button causes the MINI54 to take control and it should come up as a USB HID device (USB ID 16C0:0478) which the Teensy Loader recognizes.
Originally Posted by zachtos
Here's more detailed info, with the signal you should see on the MK20 reset lines, and a way to tell if the MINI54 is alive.
If you do figure out what's really wrong on your board, please post a followup. I'm hoping we can get more of these threads with final resolution posted (so many simply get no more responses once the problem is found and fixed).
Even if it's something trivial like the reset signal wired to the wrong place, please post a final followup when it's resolved.
Thanks, I have more boards coming this week. I'll try the above ideas and keep trying to figure out solution. I'll post if I figure it out.
Originally Posted by PaulStoffregen
photo from when I attached scope to RESET_B on MK20
- nothing changes when I press reset floating pin 20 to GND on MINILAN54 from teensy store.
-please note PIN 8 on MINILAN54 is connected to PIN 34 on MK20, schematic is out of date
That's definitely not right. When the MINI54's P5.2 pin goes low (and stays low), it's supposed to respond by pulling its P3.2 pin low.
Originally Posted by zachtos
Does the P5.2 pin at least "float" high? In other words, is it 3.3V? Does it stay at (or near) 3.3V if you connect a 1 meg resistor to GND?
This may be totally unrelated, but I'm kind of suspicious about the VREGIN being tied to VOUT3.3 and VDD1-3. From what I see, VREGIN is part of the USB subsystem. Your schematic tells us that USB will NOT power the Teensy. Fine. However, I'm not sure if you can connect VREGIN to 3.3V. Actually, chapter 184.108.40.206 of the K20 datasheet specifies: "When USB is not used in the application, it is recommended that the USB regulator VREGIN and VOUT33 pins remain floating." Teensy's jumper between VUSB and VIN can separate VREGIN from VUSB, but the Teensy is still powered through VREGIN.
Your schematic doesn't tell us where your 3.3V come from. Do you have a power supply that is fixed on 3.3V or can you raise this voltage a little bit?
If you can raise it, I would suggest to use the original Teensy approach to feed between 3.7 and 5 V to VREGIN and use the stabilized VOUT33 supply for VDD1-3 and the other peripherals.
If your 3.3V supply is fixed, maybe (Paul?) you can use it to power the peripherals and VREGIN. Then feed VOUT33 to VDD1-3. That would make the Teensy core run at a lower voltage (2.9V?) and all digital output lines would only reach that level (make sure your peripherals are fine with it). From some other thread in the forum, I understand the the core runs fine until about 1.8V. Digital inputs would receive 3.3V, but nothing should happen, as they tolerate a higher input voltage than VDD.
However, as I said: This may be totally unrelated and - mainly the last paragraph - is just guessing. I would like to hear Paul's opinion on that...
The USB gets its power from VOUT33, so if you want the USB to work, there must be 3.3V there. It can come from the on-chip regulator, or you can apply your own 3.3V.
As far as I know, the USB and SPI are the only parts of the chip which depend on 3.3V. I have not tried running the rest of the chip at a lower voltage, with 3.3V on VOUT33, so I really can't say with confidence whether that really works. Seems like it should. Maybe someone will try and report their results?
The SPI port has 2 different sets of specs, depending on the voltage. It's rated only up to 12 MHz when the voltage is under 2.7V.
Something else I strongly suspect, but don't know for sure, is Freescale likely uses an undocumented LDO regulator on-chip to power the CPU core. Or very likely 2 different LDOs, or a different feedback network on the same LDO, to reduce the internal core voltage in VLPR mode.
Well, I got the PCBs to work, so as far as I can tell there were pins from the factory on the MINILAN54 bootloader that may have been shorted. Simply plug in fresh PCB, then hit reset button while connected to USB with teensy loader and it will program right away. I will post if I find any other issues. Still unsure about if I was supposed to plug in 3.3V to VREGIN or just leave it floating...