MK66 (TQFP) with MKL04 - USB Device Descriptor Request Failed

Status
Not open for further replies.
capricorn one

capricorn one

Well-known member
Hate to have to ask this question since it's custom hardware that doesn't apply to everyone, but hoping someone can lead me in the right direction here.

I'm using a board with a MK66FX1M0VLQ18 (TQFP package) and MKL04 bootloader chip purchased from PJRC. I've gone this route before and had success, but this time, I can't get the USB to work correctly, and the LED never blinks. After holding the PROG pins low on startup, the power draw goes from 20 to 30mA and the USB device triggers in Windows that it's connected, but then it never gets the device descriptor and never loads the driver.

In addition, as I said, the LED never blinks.

The circuit I'm using is almost identical to the Teensy 3.6, with the exception that I'm trying to use the onboard regulator instead of external. The 5V I'm supplying is going into VREG_IN1, which appears to work correctly as I'm getting a nice steady 3.3V on the outputs. In addition, the USB device part of the circuit with the TPD3S014 is omitted. Everything else is identical

The main question, here's the crystal I'm using:

https://lcsc.com/product-detail/SMD-Crystal-Resonators_Yangxing-Tech-X322516MLB4SI_C13738.html

Now it says it's 16MHz with 9pF load capacity, but the datasheet doesn't specify, and I can't find a better datasheet anywhere on the internet, so just trusting the data on the page.

However, I am seeing the crystal startup after releasing the PROG switch. My scope is not great, but there's definitely a nice sine wave looking oscillator at 16MHz, whether it's perfectly 16.000 I don't know for sure with the tools I have.

My gut says the crystal is not a 9pF load crystal and my 16 is off.

Main question to move me along:

If the USB fails on startup with the default program loaded from the MKL04 on first startup, will the LED blink? If not... what would cause the LED to not blink. Or maybe I don't understand how the MKKL04 actually works, maybe there's no program on there yet at all? I have checked the pin with a scope as well, no signal on pin 110 (PTC5).

Also, I've gone through all the troubleshooting and forum posts I can find hoping not to have to post another one of these. So to get ahead of some questions:

PTA4 is floating, double checked that.

There is a ground plane under the crystal, it's a 4 layer board, crystal is very close to the pins with a small ground pool around them connected only to the ground pin nearby, which is connected to the main ground plane.

Having said that, I still think it's the crystal somehow, but hopefully the LED not blinking is enough of a clue for someone more informed. Thank you so much in advance!
 
That crystal should be fine. From everything you've said, especially that you do observe the crystal oscillating under some circumstance, I'd say the crystal is very unlikely to be your problem.


capricorn one said:
Or maybe I don't understand how the MKKL04 actually works, maybe there's no program on there yet at all?
Click to expand...

There are 2 simple ways to confirm whether the MKL04 chip is working and running the PJRC bootloader.

1: Measure the voltage on the Program signal. If the bootloader started up and initialized the chip, you should see 3.3V due to the internal pullup. A blank or non-functional MKL04 will leave that pin floating, which usually measures about 0.1 to 0.4 volts and can fluctuate (because it's floating), especially if you touch the wire. (if your design added a physical pullup resistor or other circuitry to the Program signal, of course remove it for the sake of this test)

2: Press the Program button. Of course the Program signal should go to zero volts, since the button shorts it to GND. While doing this, monitor the Reset signal with your voltmeter or oscilloscope. When Program is not shorted to GND, you should see Reset either pulsing or steady high, depending on the state of the flash memory in the MK66 (most multimeters will show about 0.25 volts DC for the pulsing waveform). When Program is low, the MKL04 will drive Reset low. Observing this behavior, where Reset is driven low when you press the Program button, is a clear sign the MKL04 is properly running the bootloader.


but hopefully the LED not blinking is enough of a clue for someone more informed
Click to expand...

The bootloader does not cause the LED (on pin 13) to blink. When you get a brand new Teensy 3.6, the LED blinks only because it was programmed with the LED blink example during product testing. It is the code you load into the MK66 chip's memory which blinks the LED.



After holding the PROG pins low on startup, the power draw goes from 20 to 30mA and the USB device triggers in Windows that it's connected, but then it never gets the device descriptor and never loads the driver.
Click to expand...

I'm guessing you words "USB device triggers in Windows that it's connected" mean you heard Windows make a chime sound? Or perhaps you're using the Windows Device Manager and observing the screen refresh? Or maybe you observe something else? These sorts of details matter.

The big question is what Windows really sees. That's difficult to know, because Windows gives so little info. If you can run Linux (not in a VM) on your machine, you'll get better info about what the kernel detects from the syslog file. There are programs for Windows which try to capture the USB communication, so if you can't use Linux, maybe one of those might help. A key question is whether any part of the device descriptor is actually read, and if the ID numbers are 16C0:0478 for the Teensy bootloader, or some other numbers (perhaps from a program NXP/Freescale pre-loads into the MK66 flash).


Anyway, my blind guess from all this is some sort of power supply issue, like missing decoupling capacitors. Or maybe wrong resistors (not 33 ohm) on the USB signals.
 
As always, thank you so much Paul.

That was the direction I needed to start looking in the right places. Definitely a power supply issue. I'm not sure what has happened in my design, been using Eagle for 10+ years now, but somehow my polygon pour for the GND plane on top is showing no air-wires (open connections) even though there's clearly no path. So about 4 of the GND pins on the uController are actually not connected at all. I'm guessing the internal connections are enough to get it working the way it is now, but clearly this is the issue.

I may try and and white wire my way through this, but it may not be easy for some of the pins.

Anyway, thanks again Paul. If I fix the GNDs and it works I'll repost.
 
Well.. unfortunately fixing the grounds didn't do anything, although it was definitely a necessary fix anyway. However, I'm still getting the same usb error unfortunately.

The only other guess I have is about the 33 ohm resistors, I can't find anything in the datasheet that specifies this value, other than the section about trimming the 45 ohm internal resistors using the TXCAL45DP(M) bits in the USBPHY_TX register. I'm wondering, is the 33 value possibly different for the LQFP chip? Or is it also maybe dependent on the differential impedance on my board, which may be different than a Teensy device? I kept my usb traces as a differential pair, same length with thing traces, close together and an uninterrupted ground plane underneath them the whole way, so I would think this would be good enough, but any advice on this would be helpful.

Haven't tried the linux route yet, but will get to that later probably.

Last question, just to be sure, the chip I'm trying to use is this one:
MK66FX1M0VLQ18
Did I buy the wrong chip by mistake?

Thanks in advance for any suggestions.
 
Ugh...

Okay, let me do some more debugging. Just noticed that there's no crystal waveform showing up. On the previous rev with the bad ground connections, I was able to see the 16MHz crystal waveform on the pins. Currently, not seeing that, so obviously that needs to be sorted first.
 
capricorn one said:
I'm wondering, is the 33 value possibly different for the LQFP chip?
Click to expand...

33 ohms worked perfectly on the reference / prototype board which used the LQFP part.


Last question, just to be sure, the chip I'm trying to use is this one:
MK66FX1M0VLQ18
Did I buy the wrong chip by mistake?
Click to expand...

That's the correct part number. In fact, you can even read it on the chip in the reference board photo.

ic_mkl04_refboard2.jpg
 
Thanks again Paul, I was pretty sure on all these details but always nice for a sanity check along the way.

Found the problem, maybe one for the bootloader chip page, maybe not.

As usual, I didn't give you all the information, so maybe if I had you would've suggested this from the start. But I'm not using a USB connector on my board, rather hard-wiring the connector to the board from a spliced cable. Done this many times without issue, including on the teensy hardware (thank you for pulling those pads out!!).

What I have not encountered before though, is a USB cable where GREEN is DATA+ and WHITE is DATA-. Quick google search will tell you this is not the convention, however, as we know, "conventions" are not standards. Alas, just needed to swap the green and white wires and everything (including rev 1 pcb) is working now.

I think I saw something about this in a post about the Error 43 usb message somewhere, so I probably should've tried it sooner, but either way, maybe a sentence on the bootloader page saying that green and white are not always plus and minus, if for no one else, for me in the future when I likely do this again.

Thanks again Paul!
 
I added "When hard-wiring a cable, check the pinout as wire colors inside USB cables may not follow conventions" to the troubleshooting tip about swapping D+ and D-.
 
Status
Not open for further replies.
Back
Top