Custom Teensy 3.2 Board: Board Not Recognized by PC

Status
Not open for further replies.
Hi Everybody,

I've got a custom board that's based on Teensy 3.2 design, but the device wouldn't be recognized when connected using USB port to PC. There's a workaround that we've found after a lot of head-scratching, but it still doesn't reveal the real reason behind the issue. So, I'm sharing the necessary schematics here for a potential solution.

Here are the details.

There are two boards stacked on top of each other similar to shields. I'll refer to the stacked boards as module. The bottom board contains MK20, MKL02, on/off controller, as well as the RESET switch and other components. The top board contains the USB connection and a power switch to switch the device on/off among other components. The two boards are connected to each other using headers. The schematics attached show how the mentioned connections.

The header connections and required soldering were done at factory and then they were sent to us. When the batch arrived, I connected the boards, but none of them were detected by PC. I've checked the cable and it's a data cable allowing code to be uploaded; I've also used other cables, but to no avail. I tried pressing the RESET button, tried to switch the device on/off using power button, and tried combinations of RESET/power switch, but nothing helped. We went through the threads in this forum and tried different alternatives, but it wasn't helping. We did find a temporary fix though.

After a while, we found an alternative which consisted of detaching the boards, cutting a USB cable and soldering the wires to the bottom board using VUSB, DN, DP, and GND connections. We didn't opt for this option initially because detaching the boards needs soldering and the boards are a little fragile. Surprisingly, after detaching the two boards, the board was recognized and code was uploaded successfully. Mind you that while the top board was stacked on top of the first board the board was not recognized even though the USB wires were soldered to the mentioned pins. However, after the first upload, I de-soldered the USB cables from the pins, stacked the top board on the bottom board and connected the module to PC using USB connection and everything went normally: the board was recognized and any code uploads would go normally.

This is quite surprising since we've used teensy 3.2 before without having any issues of this sorts. More surprisingly, it looks like it's a problem that is eliminated after the first code upload.

Has anyone come across such a problem before? Any ideas as why this is happening?

https://www.dropbox.com/s/xuf38ojkqkelqv1/MCP73833.jpg?dl=0
https://www.dropbox.com/s/7lv0l2piygtz8kj/MK20-MKL02-USB.jpg?dl=0
https://www.dropbox.com/s/xfrgmvh8yqmthpw/STM6600-TPS73733-Headers.jpg?dl=0
 
Is that a Reset or the standard Program Button that puts the bootloader chip in charge to prep the MK20?

Perhaps when reconnected the USB was soldered better across the two boards the second time? Also the runs for USB signals have some limiting tolerance requirements of DP and DN matching - perhaps that is on the edge

Have all the uploads had the sketch with an Active Usb stack? Does it still work after uploading a 'Type: USB NONE' sketch? That would require a Program Button to upload the next time.
 
I'm confused by your schematic. Your description says the chips are located on one board and the USB connector on the other, but I see both right next to each other on the schematic.

I also see 22 ohm resistors. They should be 33 ohm.

Maybe for testing remove D11. Not all ESD protection diodes are created equal...
 
Hi All,

@defragster, the button is a standard Program Button. I was referring to this button as RESET, my bad.

The headers were never de-soldered; the two boards were simply detached by separating the headers. The USB wires were soldered to the headers on the bottom boards.

USB settings were the default ones. I'll have to check if it was changed. Would this play a part in the device not being recognized by PC despite pressing PROGRAM button and/or power button?

@PaulStoffregen, you're right. The schematic I attached shows the chips and USB connection side-by-side; it was meant to keep everything together for brevity by focusing on these parts of the board only.

Thanks for pointing out the 22 Ohms resistors. Perhaps the 22 Ohm resistors are causing a problem although we've used them for a while now in different designs and didn't face any issues. I'll change it to 33 Ohms to be on the safe side.

D11 was a potential source of concern for us as well. Could D11 be the only reason the firmware wouldn't upload the first time?
 
Could D11 be the only reason the firmware wouldn't upload the first time?

Seems unlikely.

Your message described many things you tried. With a custom board we can't see and a schematic that doesn't make clear which parts are on which boards (and even with better docs) it's extremely difficult to guess what the real cause of your custom board problem might be.

But I can tell you one thing with certainty. A brand new custom board will always require pressing the program button (or otherwise causing the program pin to go low) for the first time programming. Likewise, if you ever program code onto the board which doesn't properly communicate over USB, a physical button press is required. Because the board isn't talking on USB, your PC can't successfully ask it to go into programming mode. Of course, with a brand new board having a blank MK20 chip, there won't be any code to talk over the USB for Arduino's request to enter programming mode.

Perhaps you tried the normal Arduino upload button, and when that didn't work you began trying many different things simultaneously? Perhaps you soldered the USB wires directly around the same time you first pressed the button (or otherwise causes the program signal to pulse low), and it seemed as if soldering the USB wires to a different place was what caused everything to start working.

Perhaps something else was wrong the first time you pressed the program button, causing everything to fail. Maybe you fixed that, but didn't try the program button again before soldering those USB wires, then on the next attempt the wires appeared to make everything work, but it would have actually worked without the wires moved, because of some other problem you already fixed?

Or maybe there really is some very subtle hardware problem here? Really impossible to say. Even with clear docs, very difficult to guess.

But it is well know that every MK20 chip you buy from NXP/Freescale comes blank and can not possibly respond to merely clicking Upload in Arduino. A physical button press on your board is always required when the MK20 chip doesn't have good code that can hear the USB request from your PC. That is the one piece of advice I can give you with good clarity. Hope it helps.
 
Perhaps you tried the normal Arduino upload button, and when that didn't work you began trying many different things simultaneously?

Initially, only Teensy uploader (teensy.exe) was used with the .hex files, but to no avail. Then, attempts were made to upload the code using upload button with hardly any luck. In all cases, the upload was attempted with and without the PROGRAM button on independent trials.

Side question: aren't all MK20 chips shipped from PJRC pre-loaded with a blink sketch (MK20 and MKL02 chips were purchased as pairs from PJRC)? Wouldn't that enable the MK20 to hear USB request?

My guess is also that there's something else at play here; maybe it's D11 that's got something wrong, maybe separating boards nudged some connection, maybe it's the 22 Ohm resistors or maybe it's something interfering with the connections. However, I've had success with two boards having the same exact issue and the one common denominator the two boards shared was that they were both detected by PC immediately after the boards were separated and USB wires were soldered to the pins. In any case, I do agree that debugging a custom board is not an easy task esp with so many potential factors at play.

Thanks for your feedback @PaulStoffregen and @defragster
 
The MK20 has no loaded software. The MKL02 if bought from PJRC will have the bootloader. I have had 3.2 type devices on my own PCA's and now moved to 3.5 type on newer PCA's and have little to no issues. Well, the 1st runs are my mistakes but the work out was ok and went ahead to produce nearly 250 PCA's under 3.2 Teensy design.
The board have to be programmed when we get them and via pressing the button. No blink software is loaded in the MK20's. The boards are not seen when you 1st hookup the the PC. But the teensy loader will program.
Sometime just use the Arduino IDE and install the blink software on a new board. But you need the button to upload it. Teensy loader should pop up if not already asking to press button.
You do not need the button after 1st program.. Your run from USB plug to IC should be short and nearly direct. No looping around crystals. My newest board the USB with resistors is 3/4" away from uPc. Older boards where .5" or less.
 
Side question: aren't all MK20 chips shipped from PJRC pre-loaded with a blink sketch (MK20 and MKL02 chips were purchased as pairs from PJRC)? Wouldn't that enable the MK20 to hear USB request?

Any MK20 chips shipped from PJRC are blank, just as if you had ordered them from any other vendor like Digi-Key.

A MKL02 or MKL04 chip purchased from PJRC will come programmed with our bootloader.

A new Teensy comes with the LED Blink program. The LED Blink program is loaded on to the Teensy during the testing process when we plug in a USB cable in to test the USB connector. We don't do any programming to any processors before they are soldered onto PCBs.
 
Thanks for your feedback. I was initially under the impression that MK20's are pre-loaded with blink. My bad.

We've also designed other boards based on Teensy 3.2 design.For some reason, this design is facing difficulties with the first upload - just the first upload; everything afterwards seems to go smoothly.

I'll see if I can figure out why this design has this little bug. I'll update if I come across the solution.
 
Status
Not open for further replies.
Back
Top