Teensy -> Production

Status
Not open for further replies.
C

Cosford

Well-known member
EDIT: On reflection, this probably should have been in the project guidance section. Sorry about that.

Hi Guys,

Was pointed here from the Arduino forums by Paul as I was after a way of nicely implementing audio (http://forum.arduino.cc/index.php?topic=287664).

My usage of Teensy would be as part of a system, involving a few different types of units which work together via radio. For this purpose, of course, we would be looking to implement the solution on PCB.

Looking into Teensy for our purposes, it seems perfect. Then I came across this: https://www.pjrc.com/store/ic_mini54_tqfp.html
Is purchasing this chip directly from PJRC preprogrammed the only real way of implementing a teensy design onto PCB? As you can expect, I am trying to keep production costs down as much as possible. In terms of quantity, a complete system would be composed of ~100 or more devices and as such, cost on the microcontroller front is important to us.

Are there any other caveats to implementing the teensy design on PCB? Would the main uC require a bootloader? If so, how do we go about getting that onto there? Or is that through the mini54?

Regards,
Iestyn.
 
Last edited:
How big is your board? Are you hand-soldering or SMD assembling the rest of the components?

The teensy is very compact and well laid out. I find it hard to believe for 100 units you can save money redesigning the teensy board versus using a "plugin" type setup where the teensy plugs into the board.

Remember you can get teensy 3.1 for $17, that's really cheap; producing your own would only save you a couple bucks at the still-somewhat-low quantities of 100. Paying someone capable of designing a sophisticated microcontroller board will be thousands in time.

It's 10x easier for most uses to design minor components surrounding the teensy which the teensy interacts with, than the teensy itself.
 
Is purchasing this chip directly from PJRC preprogrammed the only real way of implementing a teensy design onto PCB?
Click to expand...

Yes, unless you are absolutely positively sure you'll never need to change the program. If that's the case then you could make one programming board with the Mini54 etc. and your production boards just use the MK20DX[128|256]. The Mini54 is only required to upload new code, it isn't used once the MK20 is up and running.

As you can expect, I am trying to keep production costs down as much as possible. In terms of quantity, a complete system would be composed of ~100 or more devices and as such, cost on the microcontroller front is important to us.
Click to expand...

For 100 units I'd stick with the Mini54 unless you never need updates, in which case I'd go with separate programmer boards and production boards.

For 10,000+ units I'd pay a professional programmer to skip using Arduino/Teensyduino code and develop on the Freescale directly, and either code using a JTAG programmer or something like the USB DFU bootloader that Fadecandy uses.

Are there any other caveats to implementing the teensy design on PCB?
Click to expand...

Follow the schematic exactly. Check and recheck your schematic, then check it again. If you have to deviate in any way be absolutely sure you know what you're doing. This forum is littered with posts from people who tried to implement their own design but didn't adhere to this.

Would the main uC require a bootloader? If so, how do we go about getting that onto there? Or is that through the mini54?
Click to expand...

There's no bootloader on the MK20.

When you press the 'program' button the Mini54 takes over the MK20 via JTAG and uploads a new program to the MK20's RAM and then tells the MK20 to start running it. This program erases the MK20's flash and then writes new code to it via data from the USB port.

I hope this helps.
 
@Tomek
There will actually be three boards to integrate Teensy into, each with different circuitry and components and of different sizes. But generally, these boards will be maybe ~40 cm squared. The vast majority of components will be SMD, with a few resistors deliberately through-hole.
Whilst a 'system' has maybe 100 units in it, in time we intend to produce several systems.

@Potatotron
I'm glad to hear that the Mini54 is only for programming the mk20. Whilst we do intend to update the firmware running on the devices, this would not be very often once the initial firmware release is done. Maybe once a year (baring in mind the large quantity of devices that would simultaneously need to be updated).
I assume I wouldn't have any problems simply integrating the Mini54 into a programmer and just bringing out the necessary connections to the mk20 to headers upon which the programmer could just plug into?
Thank you for your advice regarding the schematic. I intend to base it upon the Teensy schematic, to the letter, assuming this schematic is 'to-date'? https://www.pjrc.com/teensy/schematic.html
Thanks for the clarification on the bootloader/programming situation. I've come over from Arduino and ChipKit and I can now see the way the Teensy board works is quite different, in contrast to the way ChipKit uses a similar programming methodology to that of the Arduino Uno (and similar).

You've both been very helpful. Many thanks. =)
 
I don't have any solid data on issues people's custom PCBs have faced, but from the many anecdotes (collected very unscientifically only in my memory), it seems most reported (and actually resolved) problems fall into 2 categories:

1: Trouble with the crystal

2: Random human errors - all sorts of stuff, no one theme

If you use a crystal rated for more then 10 pF load capacitance, add 2 capacitors to your layout. You can tweak their values later, but if you have no room to add them, it's likely to be another PCB spin.

Place a ground plane under the crystal, either on layer 2 if a 4+ layer PCB, or on the back side if only 2 layers. NEVER route any digital signal directly underneath the crystal. Routing on layer 3 or bottom is ok, if you have a ground plane on layer 2.

If the ground plane is on a 2 layer PCB, it's best to use only a small ground plane just under the crystal, and avoid using that small plane for routing ground. Make it a small island, only connected to the GND pin right next to where the 2 crystal signals connect.

Avoid routing digital signals close and in parallel with either crystal signal. That crystal signals are sensitive to capacitive coupling of fast digital signals.
 
And yeah, Potatotron is right about the business side. For very small volume production, it's easy to spend much on cost reduction more than you save in actual costs. If you have lots of time and small amounts of money to send, investing effort in sales and marketing is almost certainly better.

Cost reductions make much more financial sense after you've established a clear sales trend.
 
Cosford said:
I assume I wouldn't have any problems simply integrating the Mini54 into a programmer and just bringing out the necessary connections to the mk20 to headers upon which the programmer could just plug into?
)
Click to expand...

Yep, I did a design like this and it worked with no issues (well..the 3rd rev worked without issues...on the first rev I got USB D+/D- backwards and on the second rev I forgot I needed to mirror the header pin positions...).
 
The one major caveat I thankfully came across BEFORE making my first round of boards - don't let pin 33 tie to ground during bootup. That means, don't use it for a button, ideally don't even use it as an input. At the moment (this may change in the future) that pin is set so that a ground/logic low signal will set the chip into EZPort programming mode (which Teensy doesn't uses at all). What you end up seeing is a completely nonresponsive MK20, for seemingly no reason.
 
Thanks all for your advice. I've designed a couple of Atmega-based boards, but by the sounds of things, the higher frequency of the MK20 will require much tighter and robust design. The boards will be two layer and will not be utilising any other high frequency components. (To be honest, the only reason we intend on using the MK20 is in order to reproduce reasonable quality audio from our main uC without the requirement for an additional audio chip).

I will discuss my findings here with the other members (it's a joint venture). I think I may propose using the Teensy's 'as they come' initially, with a view to, either later in development (or once we have some sales under our belts), develop our own implementation.
 
I'm trying to follow Paul's advice for crystal placement on a custom PCB, but I'm not sure I totally understand. I have a 2 layer board and I placed both crystals (16MHz that all Teensys have and 32kHz for RTC) as close to the MK20 chip as I could. The bottom of the board is a ground plane, but I made a separate copper pour "island" under each crystal. One of these pours is connected to the VBAT pin on the MK20 and the other is connected to VSS (pad31 on the schematic). Do I need to connect both of these pins (VBAT an VSS) to the ground pour that the rest of the circuit is connected to? I imagine so, but then it seems that the island isn't very separate as it should be. I imagine there is something about capacitance or inductive properties that I don't understand.

Additionally, is it better to have a shorter trace for the crystal (as in the first image below) or a trace that doesn't go below the crystal (as in the second image below). I don't know if it matters too much, but I'm trying to learn and get a handle on all this. Thanks! (also, this is my first PCB, and I'm open to any advice you have)

shortcapture.PNG

longcapture.PNG
 
From the picture:
- Connect the copper area below the crystal to GND and not VBAT
- Do not connect EXTAL32/XTAL32 (pad 20 pad 21) to GND
- VBAT goes to VCC and to a backup battery through a dual diode (on Teensy 3.x)

for Teensy 3.x compatibility:
- PTA0 is not connected in the picture. Connect it to P0.7 from the Mini54 chip
 
Thanks HWGuy. Luckily I caught my mistake of connecting EXTAL32 to ground, that trace was supposed to be one to the right on VBAT, and of not connecting PTA0. I'll have to recheck the whole PCB, it's so easy to make stupid mistakes.

Right now, I have two ground planes under the crystal, one on the same layer (not touching the pads of course) and one on the bottom (second) layer. They're connected by a via. Is this best practice, or should I have only a ground plane on one of those layers.

Also, once I have connected those ground planes to the closest GND pin, can that GND pin be connected to other components?
 
I don't like either design. This looks like the RTC end of the chip.

I would aim to make the two connections:
1) As short as possible but with the same length,
2) Running the signals adjacent to each other (differential signal)
3) Having a GND plane that connections at a single point to GND nearby (i.e. you can use a moat).

I happen to like the CFS-206 approach better to retrofitting a RTC crystal. No GND to mess around with, and the holes are not that big.

Also, I am not a big fan of signals coming in at sharp angles to pins. You are risking a thinned out signal line there because the etching process will attack that corner preferentially. Instead, come in at right angles or come off the tip of the pad with any angle you like. By only connecting to the pads at their respective ends, you also make visual inspection of the pin connections later much easier.

pcb-top.gif

The below shows one interpretation of mine. Note that some connections (3.3V) are done from the 'wrong side' re: my above advice. The blue layer is GND, all the top layer that is not signal is also GND. The CFS-206 is designed to be installed on the other side of the PCB relative to the MCU.
 
Last edited:
I am wondering if I could make a programmer with the mini54 and just use the kinetis in the actual production units? That way I can still use the fast USB for code development and uploading but save some costs for the bom.
 
MacroMachines said:
I am wondering if I could make a programmer with the mini54 and just use the kinetis in the actual production units? That way I can still use the fast USB for code development and uploading but save some costs for the bom.
Click to expand...

Yes, you can do this; I did it in a prototype last year.

I ultimately abandoned this approach and went with a Mini54 on each board because without the programmer chip the MK20 is unupgradable and unpatchable.
 
Status
Not open for further replies.
Back
Top