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.
I drove to Mouser and got a P&E Multilink-U (>$100), 2 additional processors ($6), and a few other spare parts.
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:
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 will reply to myself to create a separate "thread" for each related issue.
New layout:
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
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:
Thanks again!
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:
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:
2) On the FRDM, 2.2uF caps are used at all VOUT33 pins:
3) On the FRDM, decoupling caps:
4) To limit the slew-rate per errata:
5) Thermal pad:
6) VBAT:
7) The reset switch is mounted on a different PCB than the CPU:
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:
As described the slew is approximately 10mV/uS = 10V/ms = 10kV/sec; well within both specifications.
Below is a scope of SWDIO (red) and SWDCLK(yellow).
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:
2) My chip is doing nothing:
There is no feedback from anything besides the "it didn't work" dialog.