Custom board using MKL04 - yield problems

Status
Not open for further replies.

jonr

Well-known member
I've built a custom "teensy" board that uses the MKL04 chip. Problem is that only 1/3 of 20 boards are working (ie programming with Paul's bootloader code and then showing up as a USB device) - even after a super careful inspection for solder/placement problems under a microscope.

One possibility is that my crystal layout is marginal. When does the crystal get activated - by the code that the MKL04 pushes or not until later when code is (optionally) pushed from the PC? If the latter, I can rule out crystal problems.

Another thoughts on alternatives or how to pin down the problem? "lsusb" on the PC shows no USB device. The MK20 has voltage applied and the internal regulator is producing 3.3V. The USB lines are providing USB connector to MK20 connectivity.

Voltage to MK20, USB connection, MKL04 connection - seems simple. What else is needed to appear as a USB device after pressing the "program" button?

I haven't put an oscilloscope on it yet - not sure what to look for.
 
Shortly I will be doing this as well. I am interested to find out what you solution may be. One thing that comes to mind is the USB traces. Following a tutorial listed on this site provides some good info on it. It appears that if your not accurate on the traces it can be a problem. Perhaps others with experience here can chime in?
 
It seems like I could have two cases:

a) the MKL04 loads code into the MK20 that activates the crystal and then the crystal fails and the MK20 resets

b) the MKL04 never gets to the point where it loads any code

Can I measure timing between pulses on the RESET line to identify a) vs b)?
 
When does the crystal get activated - by the code that the MKL04 pushes or not until later when code is (optionally) pushed from the PC?

After a hardware reset, the oscillator is turned off.

The crystal should start oscillating shortly after the bootloader starts running, and shortly after your program starts running.

It's always difficult to give advice about troubleshooting custom boards, especially when we can't see the board or layout. But in general, if you have a marginal oscillator layout, you can expect the same board to sometimes work, sometimes fail. Another expected failure mode involves the board always booting up, but then always or usually crashes when it drives fast edges onto the signals that capacitively couple to the crystal.

If some of your boards always work when you repeated power cycle or reboot, and others never work, that's unlikely to be a marginal crystal layout. That sort of failure is very likely to be poor quality soldering.
 
Here is the section with the crystal layout. I know, not the best, but the same layout worked reliably on a previous board. There is a continuous ground plane immediately under this top layer. There is a 3.3V power line on the 4th layer, running under the crystal (that wasn't on the previous board).

The crystal is a CX3225SB16000D0GZJC1.


Screenshot from 2018-04-24 17:16:26.png

PS - this is an open source project with full info at https://gitlab.com/our-sci


I'm thinking crystal, but I don't want to get so focused on this that I'm not looking at other possibilities. I could populate a simplified board where everything is left off but the basics to boot up.

Checking the RESET line, I see a low, non zero voltage (ie, continually resetting), so I think this is an indication that it's not getting to the point where it could load a new program over USB (ruling out a problem with the USB lines/connector).
 
Last edited:
A couple things that stand out from me. On your Ground Pin 31 looks overly wide and could possibly be overlapping the corner 32 pin? Also one of your crystal pins is running below the crystal. I recall that you want avoid routing any IO pins below the crystal. However I don't know if this includes the crystal pin itself?
 
Evidently standard behavior on a unprogrammed MK20 is to produce brief pulses on the RESET line every 50-56 usec. If you see longer than that, then the system is getting further along. If RESET stays high, then some code is successfully running. Still not clear if small differences in timing can be used to differentiate between a crystal problem and other (eg, no code) problems.

I've checked for crystal shorts to ground, but that's a good point - not clear how that ground pin pad got so wide.

There is a nearly complete ground guard ring around the crystal (should be a good thing). If I did it over, I'd try to keep the crystal's ground connections more independent of significant power flow (from MK20 to C39).
 
Last edited:
.... brief pulses on the RESET line every 50-56 usec.

Yes, that's what happens when you try to run from erased flash memory. The watchdog timer defaults to the shortest interval and repeatedly reboots the chip, because no code is present to configure it.
 
I checked and I'm getting reset pulses every 15-18 usec. This is much less than 50-56 usec, but I don't what this means. Evidently something is going wrong earlier in the startup process.
 
The reset cycles are three times shorter than expected which leads my inner old analog RF expert think that the xtal is probably trying to resonate on a wrong and higher harmonic which the PLL/FLL of the K64 can’t catch and lock onto. If the old fart is true, adding a few pF on each side of the xtal to GND could help.
 
Probably unrelated to the crystal. At this early stage in the boot process, the crystal oscillator should be in a low power disabled state. The chip should be running from its internal RC oscillator.
 
I've been reviewing the Kinetis K20 manual section 6.3.4 (boot sequence). I see that I am using pin 26 (~EZP_CS/PTA4) and that I have a 130K pull-up resistor and a small mosfet gate connected to it. But I've tried lifting this pin (where I assume an internal pullup keeps it high) - no change.

As expected, boards that work show RESET remaining high and the crystal shows a nice 16Mhz sine wave.

Robert Z suggested accurately measuring the crystal frequency to learn more about how it is loaded/pulled.

I'll order some small (1-5pf) caps.
 
Last edited:
Do the boards that work boot up reliably every time you power cycle?

If so, I'd suggest you're letting the crystal layout distract you from some other problem.
 
I haven't been able to get a good board to fail to load. I could try to mildly heat/cool the board and crystal, hoping to make it fail.
 
All good advice, thanks everyone. Eventually this will get fixed and I'll report the results.

I populated a board with just MK20, decoupling caps and MKL04 and it worked - but maybe just because it's one of the 33%.
 
Now that I understand how critical pin 26 (~EZP_CS/PTA4) is to the first boot process, I'll check for soldering/board errors that could ground it. Maybe even the gate capacitance of a mosfet makes it appear low (briefly).

In general, don't use this pin if you don't have to.
 
Can anyone confirm that pin 26 is 4V tolerant? I have a weak pull up to the voltage of a lithium battery. I think the datasheet is trying to say that all pins except 9,10,11,12 are 5.5V tolerant.

I'm also interested in what happens when the analog pins see excessive voltage. ADC failure or complete chip failure?

It looks like an unstable supply voltage could trigger low voltage reset (but I've tried using a battery to VREGIN).
 
These are the crystal that I have been using ABM3B-16.000MHZ-10.
I have used them on our older boards (3.2 types) and the newer boards (3.5) using the same IC you are using.
50 boards all programmed.
 
So the PCB in question has a USB port and uses 5V from the USB to power a lithium battery charger IC. And the CPU runs from this (typically around 4V). Every voltage checks out perfectly with a multi-meter. But, with one laptop (a Thinkpad) and under random conditions, the laptop and the charger start oscillating. This produces over 20V (peak to peak, average is correct). The result appears to be lots of dead CPUs.

Hard to believe...... and I'm not yet clear what the solution is.
 
Status
Not open for further replies.
Back
Top