Custom PCB - Teensy 3.1 with Audio board - won't boot up

Status
Not open for further replies.
Z

zachtos

Well-known member
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

Ideas?
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?

mainPCB1.jpg

mainPCB2.jpg
 
Last edited:
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:

Code: 
// enable capacitors for crystal
OSC0_CR = OSC_SC8P | OSC_SC2P;

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.

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.
 
whollender said:
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:

Code: 
// enable capacitors for crystal
OSC0_CR = OSC_SC8P | OSC_SC2P;

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.

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.
Click to expand...


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.
 
zachtos said:
... 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?
Click to expand...

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.

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.

https://forum.pjrc.com/threads/27497-MINI54-Bringup?p=61732&viewfull=1#post61732
 
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.
 
PaulStoffregen said:
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.
Click to expand...

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.
 
DS1Z_QucikPrint29.jpg
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
 
zachtos said:
- nothing changes when I press reset floating pin 20 to GND on MINILAN54 from teensy store.
Click to expand...

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.

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 3.9.1.4 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...
 
Status
Not open for further replies.
Back
Top