Using the MKL04 bootloader chip in DIY circuit to program MK20DX256VLH7 (Teensy 3.2)

Status
Not open for further replies.

markgo

Member
I have recently purchased two of the MKL04Z32_TQFP32 chips from PJRC to program a DIY circuit using the MK20 (Teensy 3.2) chip. It will not connect to the USB on the PC. I have gone through the troubleshooting guide and resolved every issue I can imagine. I have attached a schematic that represents the circuit.
One thing I am not sure of is with respect to pin 4 of the Micro USB connector. Pin 4 has no connection, so the connection is only made between pin 10 of the MKL04 and pin 23 of the MK20.

Observations:

•Initially, the reset line shows positive going spikes. I understand this to be the MK20 attempting to reset itself. The MKL04 appears to be working, since grounding pin 10 of the MKL04 causes the reset line to go low, followed by the reset line going high. (It sometimes takes several attempts for this to happen).

•When the reset line goes high, continuous data can be observed from pins 15 and 16 of the MKL04. There are some minor overshoots, but it is basically 0-3.3 and looks reasonable.

•Data has NEVER been observed on the USB lines. Whether it is following a reset, a power cycle, or anything, data never seems to be observed. Checked both sides of the 33 ohm resistors.

•All pin connections have been verified several times.

•NMI pin 26 is not connected, and is at a high level.

•The 16MHz crystal does NOT show oscillation.

•When the reset line does go high, it appears to be noisier than expected. (noise is about 0.4Vpp, going from about 3.0 to 3.4)

Notes:

•I haven’t used all of the decoupling caps, but I do have a beefy 470uF electrolytic and 2uF tantalum capacitor on the 3.3V line. It looks pretty clean.

•I am using ZIF sockets for both the MKL04 and MK20. They are not soldered. So there is a fair amount of “spaghetti” wire, but I’ve tried to keep then generally clear of noise.

Things that have been tried:

•Tried grounding the pin 10 to pin 23 connection. (Saw where some cables apparently ground the USB sense line pin 4).

•Tried using 5V from the USB as input to the 3.3V regulator, as well as an external 5V to the 3.3V regulator.

•Tried reversing the USB data lines.

•Confirmed the USB pinout, processor pinouts, etc. Confimred 33 ohm resistors.

•Tried both MKL04 chips that I have purchased, and they both act the same.

•Tried both MK20 chips that were purchased from Digi-Key, although only one of them appears to generate the pulses on the reset line, and appears to be “working”, so to speak.

teensyConnection.png
 
The connection to pin 4 on the USB is not needed, so at least you don't need to worry about that as the potential problem.

Clearly something isn't connected as it should be. Double check the wires to pin 22 (PTA0) and 25 (PTA7) on the MK20. From everything you've described so far, those are my best guess.
 
> haven’t used all of the decoupling caps

I don't have definitive data, but I think they are necessary.

Not sure that the crystal will work without a PCB.
 
Thanks guys for your prompt response!

Paul - I have checked the connections again and they still appear to be correct. Checked for shorts and continuity. With respect to the pin 4 thing, should pin 10 of the MKL04 still be connected to pin 23 of the MK20? (I tried it both ways anyhow).

jonr - With the use of the ZIF sockets, it is a little more difficult to get the decoupling caps near the chip, and they kinda end up being together on the breadboard anyhow, but I will attempt to do so. The voltage at the VDD locations does appear stable and clean though. I will let you know how it works out.

All - do you think there could be an issue using the ZIF sockets?

Thanx again,
Mark
 
Okay, I put decoupling caps at each VDD location on the MK20, plus one on the VOUT33 pin 7 on the MK20. I still cannot get a USB connection. Should I be able to see any data on the USB lines, even from the PC, or do I only get data when a device is connected? BTW - I have attached a regular Teensy 3.2 to the same PC, same USB port, and it works great and connects immediately every time.
 
You almost certainly have 1 or more wires not connected as they should be.

Maybe get someone else to meticulously check each wire? This is the sort of thing that really benefits from a fresh pair of eyes.
 
I still cannot get a USB connection. Should I be able to see any data on the USB lines, even from the PC, or do I only get data when a device is connected?

Looking at the USB signals is a moot point if the crystal hasn't started oscillating. And the crystal doesn't start automatically, so if it's not oscillating the problem (probably) isn't the crystal, but rather the communication between the 2 chips. That's why I suggested to double check those wires.
 
Looking at the USB signals is a moot point if the crystal hasn't started oscillating. And the crystal doesn't start automatically, so if it's not oscillating the problem (probably) isn't the crystal, but rather the communication between the 2 chips. That's why I suggested to double check those wires.

Hello,

check this:
- on schematic on website PJRC is PTB5 of MKL04Z32 on pin 13 on custom schematic it is on pin 25
 
I can't see anything wrong with the schematic, but that doesn't mean the implementation is correct. I would "buzz" out the board very carefully to make sure every connection goes where it is intended and not where it isn't supposed to go. When wringing out a new design it is best to not assume anything! As an addendum to Murphy's law, a colleague and I came up with a new maxim; all problems can be reduced to an off-by-one problem. While it's more tongue-in-cheek, you would be surprised how often it turns out to be true. :)

When prototyping with sockets and "spaghetti" wiring with high-speed components, things can get squirrelly. I prototype with soldered components on a PCB with a ground plane. Sometimes I need to hack it up, but you can design for flexibility to minimize the terror and cost.

Also, you might want to replace the crystal with a 16 MHz oscillator. They use a little more current (the downside), but the signal drive is much higher and it eliminates one potential pitfall with sensitive and fussy crystals. You can revert back to the crystal once you get the design bugs worked out. Digikey # 631-1071-1-ND works nicely, but it is not the same footprint as a crystal. Output goes to pin 32 on the micro and leave pin 33 floating.

The 470 uF cap is unnecessary and actually might cause issues with the charge time. 10 uF is plenty. Look up the data sheet for the regulator and follow their suggested circuit. That may actually be your problem.

If all else fails you could eliminate the boot loader chip and wire to a SWD interface (10-pin header). There is a relatively inexpensive tool called Segger J-Link (Educational version). You will need a third-party SWD adapter card to adapt from the 20-pin connector to a 10-pin (or hard wire one yourself) to load code and more importantly, debug! You can export your binary code under the Sketch menu in Teensyduino, look for Export compiled Binary in that menu. Use J-Flash Lite to load that exported binary code directly into the micro. It's easy and the code begins running as soon as it's downloaded. J-Mem program will let you examine and change memory (not a true debugger, but you will not need a USB port and printf statements to inspect memory locations).

For true debugging there is a free program called PlatformIO that uses the Teensyduino library (and your sketch!), but it does have a real debugger that works flawlessly with the Segger J-Link. I use both Teensyduino and PlatformIO. Setting up PlatformIO was relatively painless for me and it does give you more flexibility to single-step through buggy code. You will need a free copy of Microsoft Visual Studio to make it all work.
 
I kinda want to see a photo of the build with wires and zif sockets, mostly just curiosity. ;)

But absent the ability to actually see the wiring, another suggestion would be to take the chips out of those sockets and try measuring continuity for the wires between the chips from the top side of the zif sockets. I'd suggest printing the datasheets and maybe even cut out just the pinout part with scissors so you can have them right next to the sockets while touching the ZIF socket with your multimeter. Many of those ZIF sockets have a complicated pattern on the bottom side, so doing this measurement from the top side with the pinout diagrams handy might help give you a "fresh eyes" approach to really check the required wiring between the 2 chips.
 
I kinda want to see a photo of the build with wires and zif sockets, mostly just curiosity. ;)

But absent the ability to actually see the wiring, another suggestion would be to take the chips out of those sockets and try measuring continuity for the wires between the chips from the top side of the zif sockets. I'd suggest printing the datasheets and maybe even cut out just the pinout part with scissors so you can have them right next to the sockets while touching the ZIF socket with your multimeter. Many of those ZIF sockets have a complicated pattern on the bottom side, so doing this measurement from the top side with the pinout diagrams handy might help give you a "fresh eyes" approach to really check the required wiring between the 2 chips.

Yes! I hadn't considered the sockets and a picture would be helpful.
 
Thanks guys for all of your helpful notes. Here is where things stand currently:

I removed the chips from the zif sockets and soldered them onto adapter breadboards. Everything was wired back up electrically identical to the first circuit. The "spaghetti" was reduced dramatically. The circuit in-fact worked, about 80% of the time. Once it was programming, it seemed you could do it over and over without issue. Sometimes on power up, however, it would take several attempts to come up, (Reset line would keep resetting). (This issue seemed to improve by reducing the clock speed.) Following that, the chip would sometimes fail to download. Generally not working solid. So I further tried to reduce the circuit wiring where possible, by placing the crystal on the same board as the processor, minimizing wire lengths, etc. Unfortunately, now it doesn't work at all! The reset line remains in hard reset. I know it is going to sound like a wiring problem, but I know this circuit like the back of my hand now. I had two other techs look at it too. Moved the crystal back to the breadboard with no effect. I had done all this without looking at the recent posts, so I will try Loren42's suggestion regarding the cap, and Paul's suggestion of eliminating wiring as much as possible to the processor to try to get it to pulse the reset line again.

I will try to post a picture if the problem persists.

Thank you for the support,
Mark
 
Yes, it sounds like a "layout" issue. As I said, the crystal is probably the most sensitive component on the board. Start there (once you get it running again).

If you look at various successful layouts, the crystal is always tucked in close to the processor with short traces. By-pass capacitors should be close to their respective pins. Do not run traces under the crystal unless separated by a layer of ground plane. Even then I avoid the area.

Following Paul's lead I put a .1 uF cap on the reset line with a 10K pulp resistor.

The hard fault is due to something you did when you tried cleaning up wiring for the second time. You must have done something wrong. The pin spacing is very tight on the processors and even microscopic solder whiskers can cause faults. Finger test the chips to make sure they are not getting hot (a sign that the chip is bad). It is possible that you damaged a chip, too, but first go over every other possibility methodically.

Personally, I would spin a new PC board with due attention to the layout. You have assured yourself that the design works, now you have to clean up the spiderweb of wires and traces and make the layout bulletproof.
 
Hi Loren42, be mindful that this is just a "proof of concept", and is not yet a "manufactured" board. It is just in the breadboarding stage. Perhaps tolerances are so tight that a breadboarding proof of concept approach is not possible. I just fear spinning the actual production board if there is some unknown issue lurking in the mist. The "working" test board only had wiring changes external to the soldered on chip on this last go around, no changes to the pin soldering, so I wouldn't suspect any issues with the pin soldering. I may need to make a production board for testing instead of breadboarding. I will try the RC on the reset line. --Mark
 
Sounds like progress! 80% working for a little while is a whole lot more than completely dead. ;)

Maybe order the reference PCB from OSH Park? Worst case it'll just set you back $28... probably not going to break the bank?

https://oshpark.com/shared_projects/d3J03Zeb

If you're superstitious, maybe just having this PCB on the way will cause your problem to become apparent?

Or you could build 1 of the 3 PCBs and have 2 unsoldered, which might help for ohm-meter comparisons to your circuit?
 
I would say your "proof-of-concept" is pretty well accepted. Now a clean implementation would be my next phase.

Keep in mind that the Teensy 3.2 schematic is a working design that Paul has skillfully, if not masterfully, created. Following that schematic and its layout criteria will do you no harm.

Make sure every power pin has a .1 uF cap and use standard practices in layout design (you can scour the web for best practice techniques). The ferrites on his board are for RFI and EMI suppression. I would use those, particularly if the A/D is used. Paul's 3.3 VDC regulator circuit is solid. I have also used Digikey's AP2112K-3.3TRG1DICT-ND. It is rated at 600 mA, more than enough for most applications.

I grew up in the 1980s wire wrapping complicated designs for CPUs like 68020. We built high-speed (in the day) medical imaging equipment and prototyped the design on VME cards with up to 100 chips all packed on a board. These worked very well for development and took about 40 hours to wrap a board, but were ultimately replaced with 12-layer PCB boards after the circuit design was ironed out. The only reason we did wire wrapping was to prove the design concept, which often was changed due to unforeseen reasons.

Today buss speeds are faster and noise and crosstalk critical. I don't mess around with a rat's nest of wires any more and there is no need. Tools like Spice for analog work and good layout practices have rendered hand wired prototypes pretty much obsolete. The Teensy design is much simpler than the work I started and the chance of a design mistake is now so low that the risk of failure is not a good reason to avoid going directly to a finished layout.

Take heart, Mark—I think you are over the research hump and well on your way to a finished design.

As an anonymous Klingon engineer once said, "It's a good day to die! I say ship it!"
 
Okay guys, thanks for hangin in there with me. I will probably get the oshpark board or whip up a proto board on Eagle. Is there a BOM for the oshpark board? I didn't see one. I have a proto board made that runs all our stuff using the Teensy 3.2 and it works great, but for Cyber Security reasons, we are not allowed to have a board that can be re-flashed or reprogrammed. The USB port is a definite no-no. It may be some time before I can reply on the status. Thanks for all your help. --Mark
 
I think there is a security bit that can be programed in the MK20DX256VLH7 to prevent that.

If you don't need USB, why are you using the boot loader chip, which requires USB?

I think the register location is 0x0000040C, but the boot loader chip is hard coded to prevent you from writing to that address, so you will need to program the chip via the SWD port or have the chip mass programmed before soldering to the board.
 
All,

We made a board in Eagle for the circuit and have soldered it up and it works. It's the same circuit. I don't know what the difference is, go figure. But it works now and I am moving forward. Thanks for all the help.
 
Status
Not open for further replies.
Back
Top