K10 custom board

[kerbal]

I'm developing a custom board for the MK10DX128VFM5 (QFN-32 with thermal). This is my first QFN so i chose the smallest pin-count, which also works well with the project requirements (being tiny/minimalist). I ordered 3, expecting to screw up and/or destroy the first two while getting familiar with soldering them. I was expecting this chip to be so super-easy that I soldered all of the components to the first board; i.e. crystals and all. The boards after the first were assembled with only the minimal components.

Initially, I tried using the FRDM-25Z with (Freescale)OpenSDA, (P&E)OpenSDA, USBDM.

• For every assembled board and FRDM-25Z firmware combination, I tried both JTAG and SWD.
• No combination of anything worked. Paraphrased, the error message was always "It didn't work", of which I was already vastly aware.
• If I remove the debug cable and apply J11 to the FRDM board, all combinations of the above successfully deploy to the KL25Z and halt at main().
• With my custom board reconnected, any combination of pull-ups/downs recommended by ARM and/or Freescale made no difference.

I drove to Mouser and got a P&E Multilink-U (>$100), 2 additional processors ($6), and a few other spare parts.

• Going through all of the above again with the Multilink gave similar non-results.

I've switched back to the FRDM board for debugging, and inserted a small breadboard in the middle of my debug cable to allow me to:

• Reconfigure pull-ups/downs
• Source power to my board from the 25Z (or not)
• Provide the reference voltage from my board to the Multilink-U

Searching for schematics/designs relevant to the K10 produced mostly irrelevant/ambiguous results, like the K20 development board, which has two K20's, USB, and a full loadout of bells and whistles, none of which has anything to do with the K10. After wasting all this time, what seems to be the most relevant results are the errata.

I've worked extensively with pre-made boards and modules so I suppose I'm spoiled on being able to just hook up some jumper wires and it work.

• I've already revised my board layout to more closely mimic the target portion of the FRDM board, isolate power domains, etc.
• I've wasted a bunch of money/uC's
• I've replaced my perfectly good, open-source debugger with an expensive "professional" debugger for no reason
• There is a ~2 week turnaround on new boards so I would like to get this next design "perfect"

I will reply to myself to create a separate "thread" for each related issue.

[kerbal]

New layout:

• There is nothing tricky happening on the bottom side. The traces go where they appear to.
• The 4-pin connector from top to bottom is GND, VIN, 5V, 3.3V
• Forgot to turn off TORIGIN
• I elongated the pads for the uC beyond the edge of the package to facilitate hand soldering
• VBAT is currently unconnected
• RTC crystal traces will be rebalanced

[carlosmendoza]

Hi Jon,

I just saw your reply on my post about the reset line and the SWD protocol.

First of all, I have to give you kudos on being very meticulous and posting all your troubleshooting experiments so far. That's the way to do it!

I'm pressed for time at the moment so I only briefly read all your comments. You are right, you're situation is very similar to ours. All your troubleshooting ideas have been on the right track, we performed the same tests as you did in general.Your SWD signals look fine on the oscilloscope, except that I can't tell whether your SWD DIO is active low or active high, it should be active low and sit idle at 3.3V. You have probably already measured all the expected voltages from your board's VIN, out of VOUT33 and into the KL10's VDD other components. You have already checked and re-checked that your board's layout is similar to the reference designs form the freedom boards. However your reset is one of the signals that's puzzling you just like it did for us.

Well, the sawtooth behavior that you see on reset is normal. The sawtooth waveform is produced by the watchdog timer circuit (Watchdog timer - Wikipedia, the free encyclopedia). It's function is to reset the circuit continually. Wikipedia has a great explanation of its practical uses. This also explains why your reset is not being pulled to 3.3V even though you are using a pull up resistor. Every Kinetis MCU out of the factory will have the watchdog timer enabled. The watchdog timer will also be enabled when your MCU loses its firmware (this can happen every now and then during the debugging and development phase of your project).

What I found out after trying all kinds of series resistors, pull up and pull down resistors and bypass capacitors is that the quality of the SWD CLK line will prevent the reset line from behaving properly (it won't assert or it won't be released back to 3.3V). To fix this particular problem you need to reduce the capacitance of SWD CLK with respect to ground. You can do this by adding a very small bypass capacitor between SWD CLK and ground. For example, our custom board can only be programmed at 5 MHz with the Multilink FX when I have a bypass capacitor of 14.5 pF. Larger bypass capacitors will only allow your Multilink FX to program your board at slower speeds. The bypass capacitor filters out the ringing (overshoot and undershoot) on every edge of the clock. It's really just forming a low pass filter to conduct the very high frequency ripple to ground. I actually ended up removing all the other pull up and pull down resistors on SWD DIO and SWD CLK. They're unnecessary since the Multilink FX has them built in. But you might need some (10k to 100k is the recommended value) if you use a programmer that doesn't have built in pull up or pulls downs. I also removed the bypass capacitor for my SWD DIO line. But I would probably need one if I wanted to program our board at higher speeds. My reset still has its 10k pull up resistor and 0.1uF bypass capacitor. You need those both if you use a reset button on your board for de-bouncing purposes and because the Multilink FX seems to control the reset line with an open drain output pin.

Also it is *VERY* important that you test programming your board without multimeters or oscilloscope probes connected to its SWD lines. That's actually how I realized that I needed a tiny bypass capacitor (less than the 100pF that many people recommend). This is why:

Your oscilloscope probes add parallel capacitance, termination resistance and series resistance to your clock and data lines. Out of these three, the parallel capacitance had the most effect in our custom board. I realized that I could only program the board with an oscilloscope probe hooked to SWD CLK. I first had probes also hooked to SWD DIO, /RESET and VDD (3.3V). I removed these probes until I only had the SWD CLK probe connected and then I tried programming the board. If I removed the probe I would get errors (can't enter debugging mode, there was a problem with the reset line, the device is secure, etc.). If I connected the probe everything was fine. So this immediately told me that I had either a grounding problem or something wrong with the pull down resistance or capacitance in the clock line. My oscilloscope probes are rated for 10 MOhms and 9.5 pF. I tried all sorts of pull down resistors between 10k and 1 MOhm since that's what I had on hand and that didn't fix my problem. Then I tried combining some capacitors to achieve close to 9.5 pF and that's what ended up being the solution. I admit that I was at first going insane since I also realized that my probe didn't even have to be connected to the oscilloscope to have an effect on the SWD CLK line. But then I remembered that the whole cable on the probe is one big low pass filter. There's resistance built into the cable and any point on the probe can be thought of as a tiny capacitor so AC current going into the the probe will circle around even though for DC signals the probe looks like an open circuit. This is why sometimes it's good to think about the physics behind the electronics when you find problems that seem like "voodoo". Leaving stuff to "voodoo" is likely to bite your ass later during manufacturing, etc.

I would also recommend to disconnect other areas of your board to isolate the problem:

-Remove the K10's internal voltage regulator out of the equation and stick a nice and clean 3.3 V signal to feed VDD.

A very important detail:

-Every time you get the programming error you should unplug the Multilink FX programmer from the USB port on your computer and then plug it back in. Also you should close the project and re-open it (you don't have to close CodeWarrior). For us, if an error is detected then the Multilink FX forces the reset line to get stuck at logic low instead of releasing it so your pull up can bring it back to 3.3V. So when we click "retry" the SWD connection doesn't work because the Multilink FX is not letting go of reset. The only way out of this is to unplug the Multilink FX from your USB port. We have several Multilink FX programmers and it's the same for all of them. We thought the first one was broken so we bought some more. It's good to have two programmers of the same kind if your project's budget can afford it.

Then regarding closing and re-opening your project: you might also be getting errors such as "the device is secure. Do you want to erase to unsecure?" This is a That means the Multilink and CW are not having good communications. It actually has nothing to do with the K10 being secured or not. But once you get an error it is very likely that the programmer won't react. I know it sounds weird and un-scientific but it's just a firmware or software bug. I see this all the time every day. It only works when I close and re-open the project. Doing this will clean the Debugging configuations. It seems like CW remembers that there was an error and some bug causes it to not send the proper SWD initiation sequence to the MCU. At least that's what I see on the oscilloscope.

The only time the "secure/unsecure" message should actually concern you is if you manually told Processor Expert to toggle the "secure" bit. But Processor Expert will spit out all sorts of warnings if you try to do this. So I wouldn't worry too much about it. In any case these two articles by Erich Styger will save you from bricking your board if you end up securing your board:

How (not) to Secure my Microcontroller | MCU on Eclipse

Device is secure? | MCU on Eclipse

Also, start with a very slow programming speed. I started with 1 MHz and started trying tiny bypass caps on SWD CLK and then I continued to try smaller values until I was able to get the communication speed up to 5 MHz.

Let me know if this helps you resolve your problem. If not then I'll take a more detailed look at your troubleshooting comments and your board's layout.

Carlos

[kerbal]

Thanks for your reply! My little board finally fired up late last night.

You can skip all of the debugging stuff above, but the underlined parts are all of my questions and I'd still prefer to have a definitive answer on them.

I have the standard Multilink-U, so 1Mhz is my max speed.

Each time reset went low due the WD reset, it would bottom out at around 1V instead of GND. The signal would correct itself when I pressed firmly downward on the K10, and revert when I released. I hit it with the heat gun as a last ditch effort and the reset signal became consistently correct. After some more poking around (almost) aimlessly, I noticed that EZP_CS was staying low. In all previous attempts, it was always held high somehow without a pull-up. Does EZP_CS change states after a successful JTAG>SWD sequence? If so, the SWDIO/SWDCLK/XX lines were probably disconnected. If not, EZP_CS was probably shorted. Too late to know for sure now.

So, now, everything works. It flashes fine, mass-erases fine, debugs fine. Some time soon, I will try USBDM/OpenSDA/etc. again but don't expect any problems.

With all that said, I'm going to order the revised layout later/tonight. Before then, can you suggest any additions to the layout above?

This is my initial experience with custom boards (noob). Some or none of the following may apply:

• I could add the bypass caps on the SWDCLK, etc. but should I? It's no longer broke, so do I fix it some more?
• I would somewhat like to remove R4 and C1; they were added in this troubleshooting process and enlarged the original board. The board that works has neither of them. R4 was intended to limit the slew rate of VDD/VBAT per errata mask. I added C1 because it seemed "good to"; bulk input cap seems like it could go on each power module instead of the mainboard. Opinion?
• The FRDM-KL25Z has two inductors on each of the USB's coming in. Are their resistance values purely filter related, or were they selected to act like my R4?
• After programming, the final boards will be in an enclosure, possibly potted, etc. Basically, it is only intended to be re-configurable for me. Once it is sold as a finished device, the end user will have no access to it for making connections, modifications, or otherwise screwing it up. When they fail, the whole unit will be replaced. It's a bonus if I can correct failed devices and send them back out, but not a requirement.
• Some of the boards will be running radios. (noise? additional filter values?)
• Some will be running from a 12V transformer on the AC mains. (full-bridge>10uF bulk caps>regulator>filter caps>power planes with filter caps (more noise?))
• The design is stackable; since everything will be snugly and closely connected at the pin headers, can I apply bypass caps and other remedies to the elevated addon modules instead of the mainboard? How much 'bad' does using pin header connections add? I see the FRDM-KL25Z has no filters on anything leading to the pin headers.
• The electrical distance from top board center to mainboard center is just a little over 1.0 inches.
• The electrical distance from top board power side, across top board, through pinheader, down to mainboard center is just a little over 1.5 inches. Each additional layer adds ~0.2 inches.
• I'm open to adding [probably] important design considerations to the mainboard and leaving them DNP if ultimately unneeded. I'd rather do that than wait another turnaround period for version 3 to arrive.

Thanks again!

[kerbal]

e2548 -

1. Use a very low impedance connection between the power supply and the MCU Vdd pins.

This helps with the Vdd spike when the MCU goes from a full load to a no-load condition.

2. Avoid any supply ramp rate greater than 2.0V/100mS after the first power-on supply ramp.

For example, do not power up the MCU at 2 V and then ramp Vdd to 3 V later. If you want to

ramp to 3 V, do that in a single ramp.

3. Provide a clean power supply to the MCU. Ripples on Vdd can cause PORs.

My first layout routed the regulator output to:

• 10uF bulk cap
• Trace from bulk cap to decoupling cap located next to VDDA
• Traces from VDDA cap to VDD and VBAT

Would that, alone, explain all of the problems I'm having?

My new layout resembles a scaled-down FRDM-KL25Z:

1) On the FRDM, 10.0uF caps are used before and after the external regulator:

• My new layout includes one 10uF on the regulator's input (5-12V)
• My new layout includes one 10uF on the regulator's output (3.3V)
• Why 10uF? These are bulk storage caps and just need to be "big"; correct?

2) On the FRDM, 2.2uF caps are used at all VOUT33 pins:

• The value should be a function of the frequency of processor demand and the amount of ripple coming from the regulator.
• Why 2.2uF? (with 3.3V?) Was this precise value calulated through testing or simply a "good value" when using 3.3V regulators?
• Using a 3.3V LDO, my new layout includes one 2.2uF on the regulator's output

3) On the FRDM, decoupling caps:

• C5, C6, and C14 are 1.0uF
• C10, C11, and C13 are 0.1uF
• They are grouped in two's around the VDDx pins
• Per the actual, physical, board I have:

1. One VDD pin has two 1.0uF (C5, C6)
2. One VDD pin has one 1.0uF and one 0.1uF (C13, C14)
3. One VDD pin has two 0.1uF (C10, C11)

• It "seems like" one of each cap should be at each set of pins, but the lacing on the board indicates otherwise.
• Why? Are there specific reasons to provide different specific values at specific VDD pins?
• My new layout includes one 1.0uF and one 0.1uF at VDD/VSS
• My new layout includes one 0.1uF at VDDA/VSSA

4) To limit the slew-rate per errata:

• The regulator output is connected to one 10uF cap, one 2.2uF cap, and one 15ohm (1W) resistor
• The other side of the caps connects to ground directly adjacent to the regulator GND
• The second resistor pin connects to a copper pour that distributes power to the rest of the board
• The 3.3V pins that supply/receive power to/from external modules (pin header) connects to the pour
• The VDD power plane and capacitors connect to the pour via a >20mil trace
• The VDDA power plane and capacitor connects to the pour via a >20mil trace
• 10k pull-up for !RESET connects via trace to the VDD power plane

5) Thermal pad:

• True or false?: Soldering it is recommended, but not required
• It is my intent to reflow only the edge pins and begin testing
• To help reduce the chance of destroying any more chips, I reduced the number, and increased the diameter of the thermal vias under the chip. If anything useful happens on the chip, I may consider hand-soldering the thermal pad through the way-oversized vias. I made them large enough, that I should be able to do the fill very fast, by hand, and without even using my microscope.

6) VBAT:

• I haven't figured out if, and how, I'll route VBAT; is it not in a convenient location with my layout
• I'm considering running the outside edge of the trace along the current outside edge of the exposed copper, but I suspect that's not actually a good idea
• Can I encroach on(under) the thermal pad when routing 3.3V to VBAT?
• The errata pertaining to VBAT slew-rate suggests adding an inline resistor to the pin, indicating that a long route for VBAT would be acceptable and even potentially helpful.
• With the slew-rate already corrected, would a long trace for VBAT still be acceptable?

7) The reset switch is mounted on a different PCB than the CPU:

• The 10k pull-up for reset was on the CPU PCB and will remain there
• The 1uF cap on reset was located on the PCB with the switch
• The 1uF cap on reset is now located on the CPU PCB near the external pin connection
• An uninitialized chip supposedly outputs a square wave on the reset pin...
• My reset pins all went partially high, but then immediately began a parabolic discharge. There was no width to the drive and, although I didn't measure it specifically, I don't think the reset pins ever reached a full 3.3V before beginning to drain
• The pattern repeats at the correct interval, despite its' shape

[kerbal]

Probably relevant errata:

e4949 - Device may not exit the power on reset (POR) event correctly when the Vdd ramp-up slew rate is greater than 17 kV/sec as VDD is raised from 0V to 1.7V.

e2666 - Ensure that the ramp rate is slower than 50V/ms on VBAT. Another option is to add a resistor (100 ohn to 1 KOhm)in line with the VBAT supply pin. This impedance increase eliminates the latchup condition.

I didn't bother to measure exactly what mine was, just verified that it was >1000000x out of spec.

Testing:

• Using a 9V snap-connector battery and 15ohm resistor
• The resistor value was selected to limit the OUTPUT current of the 3.3V regulator to its maximum average (~200mA)
• The resistor was used on the INPUT instead due to physical constraints
• Testing my two most promising boards, the resistor on the INPUT limits the slew-rate to a little less than 10mV/uS
• The VBAT trace was cut on one of those two
• Still, neither board worked. The screenshot above of SWD waveforms was captured under these soft-start conditions.

As described the slew is approximately 10mV/uS = 10V/ms = 10kV/sec; well within both specifications.

[kerbal]

Below is a scope of SWDIO (red) and SWDCLK(yellow).

• The first rising clock edge after the first falling data edge is the SWD stop bit
• The line is driven high and then "parked"
• The first clock of the group of 4, should be the turnaround clock
• For the next 3 clocks, my chip should ACK with b100 (little-indian)

At the rising edge for each bit of ACK, there is a small drop in the data line...

Possibly:

1) My chip is trying to pull the line low but can't or doesn't:

• Assume there are no electrical shorts
• Assume there is insufficient filtering and other neglected design issues and/or errata
• If the chip IS responsible for the drop, then it is alive and was not destroyed during soldering
• If the chip IS alive, it seems to be aware of WHEN it should respond, indicating that the internal oscillator is probably running correctly
• What would cause a correctly soldered and otherwise-working chip to exhibit this behavior?

2) My chip is doing nothing:

• I fried every one of them while soldering
• The drop is the result of the debugger sampling the line
• Is this possible/reasonable and likely?

There is no feedback from anything besides the "it didn't work" dialog.