Problem with Teensy clone: loads code in IDE but GPIO unresponsive

Status
Not open for further replies.

bogasaur

Member
Hi forum,

In an attempt to start developing in Cortex-M4, I've been working on trying to make a Teensy clone using Paul's MINI54 bootloader chip and the Teensy's MK20. This custom PCB is a square and loose rendition of the original. I assembled the components first using solder paste, and then used an iron and some wick to get rid of the excess bridges on the two main IC's. I've attached images of the board in this post.

At first, I plugged it into my machine and loaded a simple blink sketch to test if it would load code. It was unresponsive and the Teensy loader did not show up. I then reworked the pins manually by chasing solder across the pins to make sure that they were all well connected. Afterwards I plugged the Teensy back into my USB port, and it loaded the code! The Teensy loader showed up, I pressed the reset button, and the loader displayed "Reboot OK".

However, when I went back to test with a multimeter for whether the broken out GPIO were actually working with the blink sketch, they were either floating or completely 0V. Pins 14, 15, 16, 17, 20, 21, 22, 23 were broken out and tested with the blink sketches, with no signs of life. Another thing I noticed when I went back to the IDE, is that the USB port with a specific number was never picked up. It is as if the code was "loaded" in software, but not physically loaded into hardware. The loader confirms that the reboot is OK, but the Teensy itself is not functioning as if has been programmed. What accounts for the software saying that the code is loaded in the Arduino IDE with Teensy loader but the custom PCB itself not functioning?

This is my test code:

void setup() {
pinMode(13, OUTPUT);
pinMode(14, OUTPUT);
pinMode(15, OUTPUT);
pinMode(16, OUTPUT);
pinMode(17, OUTPUT);
pinMode(20, OUTPUT);
pinMode(21, OUTPUT);
pinMode(22, OUTPUT);
pinMode(23, OUTPUT);
}

void loop() {
digitalWrite(13, HIGH);
digitalWrite(14, HIGH);
digitalWrite(15, HIGH);
digitalWrite(16, HIGH);
digitalWrite(17, HIGH);
digitalWrite(20, HIGH);
digitalWrite(21, HIGH);
digitalWrite(22, HIGH);
digitalWrite(23, HIGH);
delay(2000);
digitalWrite(13, LOW);
digitalWrite(14, LOW);
digitalWrite(15, LOW);
digitalWrite(16, LOW);
digitalWrite(17, LOW);
digitalWrite(20, LOW);
digitalWrite(21, LOW);
digitalWrite(22, LOW);
digitalWrite(23, LOW);
delay(2000);
}

Assuming perfect assembly, my list of possible reasons is:

  • too much heat with rework
  • faulty design

My understanding is that the USB connects directly to the Cortex-M4, which communicates with the bootloader to then overwrite the M4 so that it can accept the USB data. In this case, our problem suggests that there would be something wrong with the M4 or its circuitry rather than the bootloaders. A non-functioning M4 also offers an explanation as to why no USB port was detected on the Arduino IDE end. What are your thoughts?

Please let me know if I should provide any further materials if that would help out.

Your input means a lot. Thanks very much for all of your time!
 

Attachments

  • IMG_20150630_220352388.jpg
    IMG_20150630_220352388.jpg
    127.4 KB · Views: 539
  • IMG_20150630_220359455.jpg
    IMG_20150630_220359455.jpg
    82.9 KB · Views: 388
Last edited:
As I understand things, the bootloader on the Cortex M4 and is coded as a USB device, so the USB is really running on the M4.
If the PC loader is happy then there must be a functional program capable of USB communications running on the M4.
This would mean the M4 is not dead and can run code, but there might be other problems that shows up when initialising the
Teensyduino libraries.
 
Please post a schematic.

From the pictures it looks like there is no connection from 3.3V to VBAT (Pin #21 from the MK20DX256VLH7).
 
Hi guys, thanks for the fast responses!

mlu: I think what you're saying sounds right, since the USB data lines are connected directly to the M4. What kinds of problems do you mean?

HWGuy: Thanks so much, you're right, pin 21 isn't connected to 3.3V. Would that do the trick? I will try manually connecting VBAT to 3.3V. I've attached the schematic. I'm assuming there are more potential mistakes. Now that I've looked at the schematic, VBAT is directly connected to ground, which doesn't seem right at all. Thanks for all of your help guys! Really means a lot.
 

Attachments

  • teensy_snapshot.JPG
    teensy_snapshot.JPG
    84 KB · Views: 437
Yes VBAT needs power (Min 1.5V).
From the Ref Manual
Any attempt to access an RTC register, except the access control registers, when VBAT
is powered down, when the RTC is electrically isolated, or when VBAT POR is asserted,
will result in a bus error.
The Teensy startup code (in mk20dx128.c) does access the RTC register.
 
Last edited:
What I could see from the schematic/pictures:

Missing connection from R6/C3 to VREF-H on the pcb. The schematic doesn't look right. Usually there's a big dot for the connection of the 3 wires.
d4Capture.PNG

Minor "mistakes"
  • do not route signals (D17) below the crystal. For more information see chapter 2.1.3.3.2 from the Kinetis Quick Reference User Guide
  • unnecessary diode D3.
  • unnecessary wire from P3.4(MINI54) to D7.
  • place the decoupling caps closer to the ic pins/pad.
  • Keep traces short. Why is Ferrite3 so far away?
 
Concur. Some additional points:
Ground plane is largely missing. IMO, that's trouble! At the very least you need a ground plane under the crystal that is attached to VSS on the pin next door to help shield the crystal.
I'd place the de-coupling caps on the same side as the MCU. Less work if you ever reflow solder.
I don't see the point in having the Mini54 where you have it. The long snaking digital lines = trouble. Put the Minitan54 at the bottom of the MCU, use the QFN 5x5mm version. Much easier to implement and smaller. Library is posted here.
No need for the SDA/SCL connection between the MiniTan54 and the MCU.
Ditto for Pin4 on the USB connector (can be grounded), unless you plan on implementing a USB host adapter.
 
Most signal routing issues are non-critical, expect the crystal.

You MUST NOT have any digital signal routed underneath the crystal. A digital signal switching underneath the crystal will cause reliability problems.

If you have 4+ layers, it's ok to route stuff on the lower layers, as long as the layer directly underneath the crystal is a ground plane.
 
Isn't the SDA/SCL connections to the MiniTan "Reserved For Future upgrades/updates of the bootloader"?
 
That's a nice little board but some very interesting signal routing hehe. I am always very careful with my usb data lines always try and keep them short as possible and as straight as possible with no sharp turns or kinks. I think in this case it is ok as usb here is relatively low speed. But definitely something to keep in mind for future designs :)

(Above advice usually best practice for most traces ) not so important on low speed designs though.

Hope you get it working :)
 
Isn't the SDA/SCL connections to the MiniTan "Reserved For Future upgrades/updates of the bootloader"?

That was the idea a long time ago, from the very early days before Teensy 3.0 was released.

At this point, I can tell you that connection will never be used. You can leave it off your PCB, worry free.
 
Hi everyone!

I just wanted to say thanks so so much for all of the help. It's really tremendous. I'm now going back and redesigning the board a bit with all of your feedback, so hopefully I'll have something soon. Again, can't thank you all enough.
 
Hey forum!

Again, thanks so much for all the feedback! I've taken it and to the best of my abilities made corrections. I've made another version of a clone Teensy, albeit with the enormous help of Phillip Schuster of Appfruits. I used his schematic for the new board in his article. Please check him out here, this article truly is a gem:

http://www.appfruits.com/2015/03/building-your-own-custom-teensy/

In this version I took a bit of a twist and I decided to separate the MINI54 and the MK20 on two different boards. The gist is that the bootloading board can be plugged into the other MK20 board for programming and removed afterwards for smaller footprint when the MK20 itself is in use in a project. The board features the TI TPS61202 switching power regulator at the bottom right of the MK20 board, as it will be fed with a 3.7V lipo. Also, the header that connects the two boards is slightly "inland" on the MK20 board so that 90 degree female connectors are flush with the edge of the board.

I made sure that the USB wiring is as nice as possible with regards to differential pair wiring even with the two boards coming together with headers. Also, I made sure this time around that there are no signals running under the crystal, and also added a RT crystal. Also fixed design so that all of the supply pins have decoupling caps nearby as opposed to my labyrinth of wires in the previous board :)

Let me know what you guys think, I've attached tops and bottoms of each board. Again massive massive thanks! Wishing everyone the best,

bogasaur
 

Attachments

  • Boot_bottom.JPG
    Boot_bottom.JPG
    52.9 KB · Views: 318
  • Boot_top.JPG
    Boot_top.JPG
    65.1 KB · Views: 314
  • Main_bottom.JPG
    Main_bottom.JPG
    59.2 KB · Views: 320
  • Main_top.JPG
    Main_top.JPG
    65 KB · Views: 340
Hi again!

Embarrassing mistake on my part. I've now connected the USB VCC on the bootloader board to the VCC on the other board, added ground connections and the needed 3.3V for the bootloader. It'll have to do without a battery when in program mode though, since the PC will be feeding the connection a standard 5V. Thanks so much for the feedback everyone!
 

Attachments

  • Boot_bottom.JPG
    Boot_bottom.JPG
    65.2 KB · Views: 300
  • Boot_top.JPG
    Boot_top.JPG
    78.4 KB · Views: 324
  • Main_bottom.JPG
    Main_bottom.JPG
    58 KB · Views: 313
  • Main_top.JPG
    Main_top.JPG
    65.1 KB · Views: 321
How is your project going bogasaur?

I've been looking for an example of a custom Teensy with the bootloader on a separate board, so it's awesome to see this! Let us know if its working out.
 
I also having a working example project made in cicruit maker (altium) might be useful for you.

I will find links to it shortly.
 
I also having a working example project made in cicruit maker (altium) might be useful for you.

I will find links to it shortly.

Nice! I'd love to see that. Maybe my first excuse to play with altium's circuit maker as well.
 
I actually decided not to use USB and directly programmed the MK20 using JTAG. Not quite the epic solution, but it worked :) Can't thank you guys enough for helping out! All the best,

Dan
 
Status
Not open for further replies.
Back
Top