Custom board using MKL04 - yield problems

Status
Not open for further replies.
The charging circuit (uses a TI bq24092) is missing the output decoupling capacitor.
 
For the record, here is an improved crystal layout. Note that it has a full guard ring that is only grounded at a single point. But Paul was right, crystal issues were a distraction. The real issue was unstable Vdd.

better-crystal.png
 
Hello,
My first post here, but I have what sounds like a similar issue except with the MK66 and MKL04 bootloader. I know this thread is pretty old, but I was wondering if there was a resolution. I have the same situation where the MK66 is resetting itself continuously (70us in my case), but also only on some boards. I don't think it's a crystal/osc issue because I can see it start reliably. The sequence I see is: after activating the bootloader by pressing the button, reset goes high, I see activity on the JTAG pins, and eventually (about 65ms after reset goes high), the oscillator starts. It runs for about 3ms, then reset goes low then blips high every 70us. Reset going low seems to be what kills the oscillator (and of course it never starts again unless I press the button again, which results in the same sequence). So it would appear that even though I see activity on the JTAG lines, the code is not getting loaded properly due to what appear to be watchdog timeouts afterwards. But I have reason to believe it is because otherwise the oscillator wouldn't start. Of course all of this is prior to USB activity, so I don't think it's a routing or hardware issue there. Just wondering if anyone has any thoughts.
Thanks in advance!
 
This 70us pulsing might be coming from the MKL04 not running the PJRC firmware? That's the business model of PJRC, everything is free and/or open source, but the MKL02/04 boot loader has to be bought from them already flashed with the (not open) firmware (Paul's magic sauce). A "virgin" MKL04 will have no startup code and thus trying to reboot over and over.
 
... so I don't think it's a routing or hardware issue there. Just wondering if anyone has any thoughts.

Sounds like a flaky hardware problem. Perhaps inadequate power supply decoupling capacitors? Or a weak or faulty power supply?

Long ago, in the early days of Teensy 3.0, there was a project that had terrible startup problems. I recall it had one Arduino Mega and three Teensy 3.0 boards. That old thread is somewhere on the forum.... In the end the problems all came down to a Traco switching power supply which needed more capacitance at its input. Traco's datasheet incorrectly said such a capacitor was only required if a higher input voltage was used. It turned out the sudden chances in power usage caused the Traco become an oscillator if the sudden change in power throughput caused the Traco's input voltage to change to much. It absolutely did need that capacitor. The datasheet guidance was absolutely wrong.


I see activity on the JTAG pins, and eventually (about 65ms after reset goes high), the oscillator starts.
....
it would appear that even though I see activity on the JTAG lines, the code is not getting loaded properly due to what appear to be watchdog timeouts afterwards

NXP ships MK66 chips with a program pre-loaded in the flash, so the behavior may or may not be a direct result of the MKL04. Some of the behavior you're seeing may be a result of NXP's code.

But if it is from the MKL04, the very first thing the loaded code does is shut off the watchdog. Then the crystal is started. So the watchdog isn't a likely explanation.


Reset going low seems to be what kills the oscillator

This is another case where it's difficult to know which thing is the cause of another thing. The crystal oscillator does default to being disabled when the chip is in reset. The MK66 always boots based on an internal RC oscillator. It only starts the crystal oscillating when configured by software. Also, the reset signal is a bidirectional pin, so when you see it go low, that may be a caused by the MKL04 pulling it low or by something happening on-chip which causes a reset event.

My point is some of this reasoning about causality may be incorrect assumptions.


Very difficult to know what's going wrong here. But if this is a reasonably sized batch of custom boards (how many total, how many work flawlessly, how many fail, whether they always fail the same way, and other details were left unsaid) where some work and others don't, it's pretty likely to be a hardware problem. If the build quality is very good, so the problems can't be explained by soldering or PCB quality issues, I'd look at the power supply.
 
Theremingenieu - Thanks, that crossed my mind too. But I think that if that were the case I wouldn't see the activity I do on the JTAG lines after pressing the button.

Paul - Thanks as well for your response. I'm pretty sure the power supply is OK. It's a custom multi-stage supply (12V to 5V via an LT8607 buck converter and 5 to 3.3V with a TLF1963 linear regulator) on the board with bulk ceramic and tantalum capacitance and many decoupling caps that connect directly to the +3.3V plane and the ground plane (6 layer board with ground plane right below top signal layer). I've looked closely at the 3.3V rail during these events with a scope and don't see more than +/-20mV of ripple or spikes.

One other thing I did was to cut the trace between the MKL04 and the MK66 reset pin to try to isolate the source. After that the MKL04 side (PTA4 and PTB5) is high, and the MK66 reset pin shows the brief (~1us) blip high every 70uS or so right after the 3.3V rail comes up, so it looks like it's something in the MK66.

To your last question, we have built about 20 of these boards and had 3 exhibit this problem. We do hand solder our boards, but by someone who is very experienced and we've inspected everything and it looks good. We do realize that this is certainly a possible problem, though. We're going to try replacing the bootloader (which has worked once before). I agree that it could be a flaky design or layout issue, but we'd like to figure it out as we are working on several projects based on Teensy 3.6 and will be making them in some volume in the future. Any other thoughts you have would be very welcome. If it would help to see any scope shots I'd be happy to take them.

Thanks again
 
I have one additional piece of info if anyone has any thoughts about it. Some time ago we were having a possible brown out issues with the 3.3V supply (it had an erratic ramp up) on a different board, so we added a Vcc monitor, the TC51N2702, to the reset line, which has a 2.7V trip point and roughly 100ms timeout. It became standard practice for us to use this part. On this board there are no supply issues so it's only active at power up and thinking that the bootloader only talked to the MK66 after a button press I didn't think it would cause a problem. But I just looked at two of the JTAG lines (triggering on the 3.3V supply rise) and there is some communication right after power up (lasting about 4ms). I'm wondering if this is normal and if having the reset line asserted during that time would cause a problem. BTW - I took it out of the circuit on the board I'm having the problem with, so it's not the one causing the regular resets, but it was there when we first powered the board up. Thanks again.
 
We've had the problem a couple more times and have had limited success by replacing the bootloader, but there must be something we have wrong in our hardware. I'm hoping to get Paul's opinion in particular on possible impact of our power supply monitor, TC51N2702, if it may be causing the problem because of its long timeout, and it's really the only difference I can find between Teensy 3.6 schematic and ours. Thanks
 
I don't like the voltage drop of that device. But it's easy to determine if it's the problem by installing a jumper.
 
I have removed it on a board that was exhibiting the problem and it didn't help, but there appears to be code in the MK66 that is continuously asserting the reset line (every 70us or so it briefly goes high then low again) and pressing the bootloader button does not reprogram the device or establish USB communication.
 
If you have made the schematics the same, then that leaves power, board layout and component causes.
 
Status
Not open for further replies.
Back
Top