Teensy 3.x Crystal

Status
Not open for further replies.
capricorn one

capricorn one

Well-known member
There's a few threads in the forum about this, and I've been able to pretty much narrow my problem down to the crystal, but rather than hijack an old thread I figured I'd ask a more direct question. I've got a pcb made to use the MK20DX128VLH7 and the MINI54LAN from PJRC with the bootloader, plus a few other things, which is why I didn't use the standard teensy package. I haven't been able to get any response from the computer yet, and after some probing with my scope noticed that there is no signal coming from my crystal. So after some reading I realized I probably have the wrong one :/ I'm using an HC49 package 16 Mhz crystal with an 18pF load capacitor rating. I get that this is not the correct crystal, but is it so wrong that I will see no signal at all from these pins? Would moving to a smaller load capacitance crystal possibly be enough to get running, so that I could change the load capacitance in the software?
 
Thanks Paul, I went through that stuff after seeing the other threads, unfortunately I can't do anything to the code yet because I can't program the device. Resetting the Mini54 seems to be functioning properly, but there's no response from the MK20
 
I just realized that maybe the crystal shouldn't be running until the teensy has been programmed with a sketch? Does the bootloader initialize the external clock circuitry, or is this done in the sketch?
 
You could try soldering a pair of 20 pF capacitors onto your board. Maybe that will help?

However, most crystals will manage to oscillate with the wrong capacitance, so it's quite likely something else may be wrong.
 
Just a thought - go through and triple check your board schematic. And I mean THOROUGHLY. I made up a set of boards (like... 5 for close to $800, it's big and has many layers) and then discovered that I'd mislabeled one of my power nets - the one that comes from the power jack through a ferrite to literally everything else on the board. Easy enough fix once I figured it out, but it's nutty what problems a difference of a single character can cause.

Basically, go through it and assume NOTHING is correct - check things off as you discover they work (is the MK20 getting power? are your USB connections to it aligned properly (D+/D-)? Is the crystal seated 90 degrees off (had that happen once too!), etc etc etc. Or, if you're really convinced it's the crystal - scavenge one from an official Teensy 3, or order a couple from digikey or something and plop those on there.

For me at least, I'm dumb, and I often do dumb things without realizing it :D
 
Just a thought - go through and triple check your board schematic.
Click to expand...
Good advice. I'm thinking that must be where my problem is. So far, everything looks right, except I did notice one thing. I didn't connect the VBAT pin to anything. I thought that since I'm not using the RTC I didn't need this, but maybe I'm not understanding what that pin really does?? I'll try to jumper that pin on the IC tomorrow morning. Hopefully that solves it...otherwise I'm out of ideas. I've tried a bunch of different caps on the crystal and get nothing, so it's got to be something else.

Also...
Is the crystal seated 90 degrees off
Click to expand...
What do you mean by this? Like not soldered on properly? Or maybe that's specific to the package, I'm using an HC49 package, so I don't think you can put that one on wrong, if that's what you mean. Thanks for your help!
 
Last edited:
capricorn one said:
Hopefully that solves it...otherwise I'm out of ideas.
Click to expand...

You can't do what I'm about to suggest. It really must be done by someone else who's unfamiliar with your design.

Print your schematic. Or if your design uses the Teensy 3.1 schematic, print the Teensy one. Or if they're very similar, print both. Then have someone (NOT you) use the highlight net feature in the PCB layout software, and color the corresponding wires on the printed schematic with a highlighter pen.

Obviously this is boring, tedious work. Even if you're paying someone to do it, offering a special inventive or bounty for finding the mistake can be motivating.
 
Ah, yeah - looks like the HC49 probably doesn't matter too much with regards to placement? The crystals I use are SMD, and they have four pads - and are very nearly square. If the pins are arranged in clockwise order (1/2/3/4), 1 and 3 are ground, and 2 and 4 are crystal in/out. It's possible to rotate the whole package 90º and have everything connected wrong, with the grounds connected to the teensy and the crystal IO connected to ground. Real fun to discover!

With regards to what Paul mentioned - getting someone else to look at the schematic is a good idea. If you're using Eagle, go through and stick a label on EVERY net (it's the icon that looks like an angled wire with 'ABC' over it). For the ones that already have labels, go through and click on them and move them around a bit - wiggle the labels. You'll get a little line pointing to the net that label comes from. It's possible you can have a label from another net that looks like it's referencing a different one. I'd say you could do that yourself, and something may jump out at you . You'll need those labels there for someone else to be able to go through and highlight anyway, so if something doesn't jump at you you still have that option too.
 
Seems like pretty much every Eagle schematic I see online isn't really a schematic at all. It's just the parts placed on a sheet, with net names attached to the pins. Sometimes they're little mini-schematics, showing how a few parts are connected to a chip, but overall the whole thing isn't representing the interconnection between chips with anything other than net names.

Just one typo on a net name, and suddenly there's no connection. It's a very error prone process. It also really makes me wonder why people bother creating those "schematics"? Really, why? If you're just going to attach net names to pins, why not just place all the components in the PCB layout and attach their pins in the layout? At least there, you can visually see if they're really connected.

Ok, this concludes my little mini-rant about how so many people use Eagle.
 
Yeah, I generally don't use Eagle that way. I tend to separate things into major sections (so on my board, that's two Teensy collections - one for the MIDI core, and one for the Screen core - as well as the USB Hub collection, and then a User Interface collection for all the buttons and such.) The UI collection does tend to suffer from the phantom net syndrome, just because I'd rather keep it organized that way than to have an extra 400 nets crisscrossing themselves over the Core teensy schematic.

Generally Paul, I agree with you. SO much harder to follow without having everything connected and traceable. I try and keep things logically organized, and sometimes that requires floating something off elsewhere to avoid jumbling.
 
Paul makes a very valid point, the widespread misuse of Eagle can be traced back to the fact that most hobbyists learn it just enough to be dangerous and don't take the time to learn it through and through. I've used it for a while and have a small bin full of bad boards to prove Paul's points (in one shape or other). For one, i should be more patient and breadboard a working solution before penning it to a PCB. I have yet a lot to learn and Eagle keeps evolving. For example, many of my library parts now get flagged for consistency issues even though they work. I've stuck to 6.4 as a result, for now.

Anyhow, there is a good reason to use net names on some signals, like GND and VCC. Depending on how busy a drawing can get due to a plethora of connections, it may also make sense to break areas down by function and connect them with net names or perhaps better, busses. That limits screen clutter and also helps ensure that the necessary connections are being made. As a check, I wiggle my parts in the schematic to see if all the nets are attached. I keep my net names very simple (i.e. D1, D2, D3, etc.) to map a particular pin to a particular device I/O.
 
Thanks for all the suggestions! I've got the VBAT pin connected to the 3.3V power now annnd am back wondering about the crystal :/ Before, there was no signal on the crystal pins (0 volts). Now there is a pretty constant 500mV voltage on the pins. So, to me it seems like the crystal isn't starting up? There's so many posts and articles out there on choosing crystal load capacitors, so I hate to have to ask this question for the millionth time, but there's a couple things I just want to make sure I understand. I know the crystal load capacitor equation everyone uses is :

CL = (C1 * C2) / (C1 + C2) + Cstray

or if C1 = C2 = CX

CX = 2(CL - Cstray) = 2(18 - Cstray)

So, my question, and specifically for the teensy, is what is Cstray. (My crystal requires an 18pF load capacitance)

I'm using a 4 layer pcb with the ground plane below the signal plane, and I calculate the trace capacitance to be much less than 1 pF. However, the mk20dx128.c sets up the crystal pins with a 10pF load (8pF + 2pF, according to Pauls post above). So I would take this to be Cstray = 20pF? or... is it 10pF?

The other question is, since I haven't been able to get the teensy to be recognized by the computer yet, is the oscillator circuit even activated yet? I thought maybe the bootloader did this, but maybe it's not even active yet?
 
I've just brought up a board with a MK20DX on it.
Technically my understanding is the MK20DX comes up on its internal 4Mhz oscillator and then under software control switches to other clock sources.
So looking for oscillations on the external oscillator may not be a primary debugging aid.
You could check the programming pins going into the MK20DX - I believe the basic protocol should require CLK/ptA0 and activity on _TMS/SWD_DIO/ptA3 for some programming.

For my custom first board build using the MK20DX, it refused to come up - I used an 8Mhz Ceramic Resonator, CSTCE8M00G55-R0 with no capacitance - small and low cost.
I spent a lot of time checking all the voltages on the Vcc pins - grounds are harder - looking at the PCB - and also checking the current on the power supply.
I have a 10x Jewelers Monocle for looking at the soldering of all the pins in detail.
In frustration I assembled the 2nd board, still with the same minimal circuitry - all decoupling capacitors, but NO external oscillators (8Mhz or 32Khz), and made sure I thoroughly cleaned it with white spirits as I went along.
This one worked.
I am using a flux pen that says "no clean", but I've found it does leave something that lowers the resistance between tracks. Its a Kester Flux Pen #951 - "Low Solids, No-Clean"
The first board I only built the basics on it as well, but I did build it and leave it for two weeks before trying it. So the only reason that I can think of for its failure is I didn't clean it thoroughly after I had built it.
So breathing life into the first board is a slog, after the 1st board I have a physical reference board. I always feel relieved when I can get a program in and flash a LED for the first time.
I am using a JLINK to program the device - for low power, symbolic debugging and more flexibility with the kinetis family - The JLINK interface was also a problem getting pull-up resistors in the right place for the SWD to talk as the JLINK device is a generic interface for all ARM processors - so I wish I could have used the Teensy3.1 in my product as it would really have saved some time :)

BTW when I did got the board programmed, no external oscillators - running off internal 4Mhz. Then later added the 32KHz oscillator, switched to it in software and low power which worked - and then in software again switching to the 8MHz - which caused it to stop responding - because I hadn't soldered in the 8Mhz Osc.
Once the 8Mhz was soldered on it its worked just fine with the 96Mhz PLL setting.

Goodluck Capricorn - channel that stubborn goat to get there .
 
Ah! Okay, got it working. Kind of a funny one, well to me it is. I'm sure if I had just shared my schematic from the start, Paul or someone else would've pointed out the problem right away, oh well, it did help me find the future problems I would've had with the crystal and the VBAT pin. So here's what it was. In an effort to minimize vias (not really sure why that was a big deal), I wasn't using digital pin 33 (PTA.4) in my design, so I routed PTA.0 pin underneath it to simplify my board layout. Unnnnfortunately, PTA.4 is actually the CS (chip select pin) for the programmer interface (EZport programming interface). So naturally, connecting the CLK to the CS pin would cause a lot of problems... Anyways, I was able to pull up the pin on the chip and everything worked immediately. Thank you all so much for your help! Paul, just curious if you have another moment to spare, how come the CS chip is not used in the EZport interface for programming? Looks like the standard MISO/MOSI are tied together, and CLK is connected, but that's it? I'm sure whatever magic you've worked in the bootloader has something to do with this, anyways thanks again!
 
Status
Not open for further replies.
Back
Top