T2M, an Embeddable Teensy Module (WIP)

[loglow]

I've been working on this as a tangent, and it's time for me to get some feedback (and help) if anyone is interested. Here goes.

Note: This is not a finished/working project, but rather a work-in-progress.

Background and rationalle

• The Teensy (especially the 4) is very powerful and can be used as the core of many different devices.
• The Teensy has an existing Arduino-compatible codebase and a strong community.
• Existing Teensy boards represent a compromise between size and usability, namely they're breadboard-friendly.
• Teensy boards are embeddable, but there are some drawbacks:
  • They require pin headers to mount and through-hole assembly.
  • This adds some extra height to the final assembly.
  • The bootloader adds expense and size, and it may not be necessary in some embedded situations.
  • If bottom Teensy pins are needed, mounting gets even more complex (and expensive).
• How small can we make an embeddable board that's fully Teensy-compatible?
• The Teensy would be used for prototyping, and then an embeddable module like this could be used in a manufactured device.
• This way we don't need to reinvent the wheel going from a prototype to a final product.
• If firmware needs to be updated by the user, we can integrate a PJRC bootloader chip sitting next to the module (maybe even as it's own sub-module?)
• This design was somewhat inspired by Sparkfun's "Creating Artemis" article: https://www.sparkfun.com/news/3122

What is it?

• This is a tiny (26 x 14.5 mm) board designed to be embedded.
• Surface-mount via reflow only, pads are on the bottom.
• Should be fully compatible with Teensy 4.0 code.
• All Teensy 4.0 pins are available.
• Does not have a bootloader chip on-board.
• Bootloader chip connections (and SWD/JTAG) are broken out for debug/flashing as 2x7 0.05" pogo pads (on top and bottom).
• Open-source design, so others can learn, modify, and benefit.

What does it look like?

This is a first prototype of the assembled board.





How do you program it?

The theory here is that you would do one of the following:

• Program it before assembly (PCBA manufacturer pre-programs the i.MX RT1062 chip (and the flash memory chip too?)).
• Program it after assembly using a custom pogo-pin fixture/jig.
• Program it after assembly (or final installation) using a pogo-pin programmer containing a PJRC bootloader chip (see below).
• Program it after assembly (or final installation) using a pogo-pin programmer/adapter connected to a JTAG/SWD device (see below).
• Program it after installation (in the field) using a PJRC bootloader chip (and a USB jack) installed next to it permanently.

Prototype programmers

Here's the first one, a JTAG/SWD adapter. This routes the JTAG/SWD pins from a standard 0.05" header to the pogo pin array. It also has a USB port and a 5V to 3.3V regulator to power the board.



Here's the next one, a PJRC bootloader adapter. Similar to the one above, it uses USB and a regulator for power. It holds the MKL02 chip with the PJRC proprietary bootloader and has a programming button. To the Teensy loader software, this setup would look like a regular Teensy 4.0. This bootloader chip isn't available for purchase yet, and hasn't even been programmed for use with blank i.MX RT1062 chips yet anyway, so I haven't assembled one of these yet. See: https://forum.pjrc.com/threads/57132...l=1#post221811



Problems

Programming this thing using JTAG is harder than I thought. I don't have much experience in this area, so it's possible (likely even) that I'm missing something big or making a stupid mistake. I'm used to using JTAG or SWD to program STM32 chips using an Olimex ARM-USB-OCD-H and OpenOCD. This is (relatively) straightforward. So, I thought, "Great, the i.MX RT1062 supports JTAG, so I'll do the same thing!" Except that OpenOCD doesn't seem to include any scripts for the i.MX RT1062. It does say that it has Cortex-M7 (aka ARMv7-M? Is this the exactly the same thing?) support. OpenOCD is not simple, and I'm not an embedded hardware engineer, so I haven't gotten very far on this front. Basically a lot of "Oh, I'll try this command" over and over with no results.

On page 189 of the "i.MX RT1060 Processor Reference Manual, Rev. 0, 08/2018" we have this:



Which leads me to think that the OpenOCD TAP ID for this chip should be 0x088c501d (assuming the underscore in "088C_501Dh" means absolutely nothing, and the lowercase "h" means "this is a hex string", both of which I could be wrong about).

So, needless to say, I haven't been able to get OpenOCD to communicate with the prototype board yet. The documentation for OpenOCD and the i.MX RT1062 chip pretty quickly leads me into a soup of unfamiliar three-and-four-letter-acronyms (TAP, DAP, ETM, ITM, TPIU, CTI, FPB) and I start to lose my mind (or feel like I need to go back to school for this stuff).

Next steps and questions

• Big-picture: Does this project make sense, on a technical/logistical/ethical/spiritual level? Do you see a utility in these boards? Are they technically feasible, or am I making a big incorrect assumption (for example, that the MKL20 isn't necessary aside from flashing the i.MX RT1062)? Is there any market for these? Does Paul like/hate this idea? I don't exactly want to cut PJRC out of the loop here, but someone could make an argument that this is sort of doing just that (although I don't think it is exactly, but it's complicated). I haven't invested much time or money into this, so I'm pretty flexible with it.
• Small-picture: Assuming I haven't made any show-stopping assumptions, the next step is to actually get the chip initialized/programmed via JTAG or SWD. Is this even possible with OpenOCD? There's other hardware (like the LPC-Link2) and other software (like MCUXpresso) that might work and/or be required here perhaps? I have neither of these tools on-hand, at the moment.
• I could give up on JTAG/SWD for now and just wait for Paul/PJRC to release the updated MKL02 bootloader for the Teensy 4.0. Then I could assemble the MKL02 programmer and see if any of the assembled boards actually work, and if they do, I could begin testing them.

That's all for now. All the files are up on GitHub (https://github.com/loglow/T2M) if you want to check them out. They're not licensed yet, so please just let me know if you're wanting to use them for any derivative work. Eventually, once this project is either working or abandoned, I'll select a free/open license for them.

Any questions or thoughts or assistance is more than welcome.

Dan

[jonr]

You may be able to program your board with the programmer built into the MIMXRT1060_EVK. Design files are available.

The PE Micro Multilink should also work.

[blackketter]

This looks fantastic! I have a couple of initial reactions:

1. I'm not sure I understand why so much board space has been dedicated to the programming pads (holes?).
If they are there for programming before the module has been soldered down, couldn't they just be pads on the bottom for a jig with pogo pins?
If they are for programming once the module has been installed, couldn't the appropriate connector be added to the host board?

2. Have you considered using castellated holes around the edges instead of under the board? This would allow simpler assembly by hand for some designs and make every pin accessible externally for probing, etc. And it should be compatible for reflow too. The reflow-only design is something that would definitely give me pause.

3. I'd love to see a spot for the PJRC bootloader chip to be included on the module. You might consider selling versions with that part populated or not. I'd probably want the part included for my use and Paul could get his well-deserved cut.

[loglow]

This looks fantastic! I have a couple of initial reactions:

Thanks!

1. I'm not sure I understand why so much board space has been dedicated to the programming pads (holes?).
If they are there for programming before the module has been soldered down, couldn't they just be pads on the bottom for a jig with pogo pins?
If they are for programming once the module has been installed, couldn't the appropriate connector be added to the host board?

I think you make a very good point here. They were another size/convenience compromise, but they take up too much space for the amount of convenience they provide (not much). I've removed them for now.

2. Have you considered using castellated holes around the edges instead of under the board? This would allow simpler assembly by hand for some designs and make every pin accessible externally for probing, etc. And it should be compatible for reflow too. The reflow-only design is something that would definitely give me pause.

I considered it, but now I'm re-considering it. At first, I imagined that the under-board pads could be smaller, giving more room for more pins and for routing traces between them. However, the castellated holes could be just about the same size: 12 mil drills with 20 mil diameters (0.5 mm). With the same 1.0 mm spacing (pitch), that leaves a 0.5 mm gap, which allows for 6/6 trace/space routing to sneak a trace between them.

3. I'd love to see a spot for the PJRC bootloader chip to be included on the module. You might consider selling versions with that part populated or not. I'd probably want the part included for my use and Paul could get his well-deserved cut.

I'll throw back the "wasted board space" argument here, in that an unpopulated chip and its support circuitry will take up at least as much space (or more) than those programming pads. Instead of the bootloader optionally being on this board, I'd like to make a second optional (smaller) board to house just the PJRC MKL20 and its components. Does that sound good?

Here's a quick mockup of the smaller, castellated board. Outer-edge trace re-routing hasn't been done yet.

The size has now been reduced down to 23.5 x 14.5 mm -- making it just over 3.4 cm² (or 0.53 in²).



PS. That Mill-Max pogo-pin header was >$20, so I'm kind of relieved to ditch it. They (kindly) sent me 2 for free.

[loglow]

I'm thinking of something like this for the bootloader board.



This is 12 x 6 mm. The pads are a bit larger, 0.5 mm drills with a 1.5 mm pitch.

This one could be easily made with the cheapest PCB tolerances too.

[Gigabyte]

If you need a bootloader chip, why not un-solder one from a T. 4 board?

[loglow]

If you need a bootloader chip, why not un-solder one from a T. 4 board?

Because they’re not yet capable of initializing an off-the-shelf i.MX RT1062. PJRC has a custom fixture to do it at the moment. Paul has said he is planning to update the bootloader code to support new chip initialization sometime next year.

[loglow]

3. I'd love to see a spot for the PJRC bootloader chip to be included on the module. You might consider selling versions with that part populated or not. I'd probably want the part included for my use and Paul could get his well-deserved cut.

Well, I had a change of heart about this, for a few reasons, including those you mentioned. Mostly, the added complexity of using both modules together (T2M + a seperate bootloader board) and an end user needing to hook them up and route them properly, it just didn't seem worth the extra hassle (and board space) for someone embedding the module. This just makes it super easy. Since I'd already routed traces for those pogo pin pads, most of the necessary signals were already hanging out over in the right-hand area of the board also.

The new draft here is larger, 28.5 mm x 14.5 mm, with 80 pins, a spot for the bootloader chip, a small programming button, and the additional few 0402s. Not completely routed yet, but all the hard routing is done and only cleanup is left.



PS. My first version omitted digital pin 9 entirely. Sorry pin 9! That's been fixed.

[Gigabyte]

Your board looks amazing, I just ditched the T. 4, because it too hard to integrate properly in to a product made rady for an EMS to produce.
How does the bottom side of your board looks like?

[blackketter]

Looking good!
Two new thoughts:

1. I don't know if it will help save any space but I'm great with leaving the programming tact switch off the board. If somebody is using the bootloader to program via USB, they can add the switch where they need it when they place the USB connector. Likewise I don't see a need for the LED, but that's tiny I suspect.

2. For development I'm really missing a system reset pin on the Teensy 4.0. Paul indicated that the bootloader code needed to be modified to support this, I haven't digested the datasheet power management documentation to understand this fully but if you do this is a pin I really would love to see brought out one way or another. (I'm wondering if the EN input on the regulator could be used for this purpose...)

Keep up the good work!

[loglow]

2. For development I'm really missing a system reset pin on the Teensy 4.0. Paul indicated that the bootloader code needed to be modified to support this, I haven't digested the datasheet power management documentation to understand this fully but if you do this is a pin I really would love to see brought out one way or another. (I'm wondering if the EN input on the regulator could be used for this purpose...)

This might be an ignorant response on my part, and this question may have already been discussed elsewhere, but... upon first glance:

Wouldn't a momentary switch (going to GND) connected to the signal between the POR_B pin on the RT1062 and the PTB1 pin on the MKL02 trigger a manual system reset?

If so, this board would already support that since it exposes this signal (all of the MKL02 signals in fact) as a pin, whereas the Teensy 4.0 does not.

However, I could see this somehow freaking out the bootloader and causing problems? This might be why Paul said that its code would need to be modified.

The MKL02 does have its own reset pin, but it's multiplexed with PTA1. On the Teensy 4.0 this pin is connected to the EMC_01 pin on the RT1062. Depending on the register config of the MKL02, if that pin is in fact configured to function as the reset, it seems possible that a dual-pole switch could assert reset on both chips at once.

As an aside: The TRSTB signal (PTA3 on the MKL02 / GPIO_AD_B0_11 on the RT1062) might perform a system reset, but it might just reset the debug subsystem, and I'm not sure which. From the JTAG page on Wikipedia: "The TRST pin is an optional active-low reset to the test logic, usually asynchronous, but sometimes synchronous, depending on the chip. If the pin is not available, the test logic can be reset by switching to the reset state synchronously, using TCK and TMS. Note that resetting test logic doesn't necessarily imply resetting anything else. There are generally some processor-specific JTAG operations which can reset all or part of the chip being debugged."

[defragster]

IIRC - Paul noted somewhere there is a reason the reset pin isn't exposed to do with bootloader as used to do what it does to get T4 function from 1062.

And attempts to trigger typical ARM reset/restart {SCB_AIRCR = 0x05FA0004;} from software end up with the 1062 OFF.

[loglow]

1. I don't know if it will help save any space but I'm great with leaving the programming tact switch off the board. If somebody is using the bootloader to program via USB, they can add the switch where they need it when they place the USB connector. Likewise I don't see a need for the LED, but that's tiny I suspect.

So, I haven't tried re-routing this yet, but I do like the new layout and size.

I removed the exposed pad on the QFN after doing some research (https://www.nxp.com/docs/en/engineer...etin/EB806.pdf, https://cache.freescale.com/files/an...ote/AN1902.pdf). Without doing so, this arrangement would be very tricky to route. Think it'll be ok, or am I asking for trouble?

[loglow]

How does the bottom side of your board looks like?

At the moment, it's just 100% solder mask (blank), no components.

However, I might add (JTAG + power + USB) test points to facilitate programming with a pogo pin fixture.

[ecurtz]

I think this is a great idea, and would love to see official Teensy releases available in this form factor (although a board like this using the boot chip so Paul gets a cut is the next best thing.) Unfortunately I'm a software rather than hardware guy so I can't be any help at this stage, other than saying good luck!

[blackketter]

@loglow, dunno if you saw this thread: https://forum.pjrc.com/threads/58943...port-to-RT1062 but it may be useful for your bringup. Also might increase the addressable market for your board, with the CircuitPython version possibly not needing the teensy chip.

[loglow]

I think this is a great idea, and would love to see official Teensy releases available in this form factor (although a board like this using the boot chip so Paul gets a cut is the next best thing.) Unfortunately I'm a software rather than hardware guy so I can't be any help at this stage, other than saying good luck!

Thanks! Perhaps you'd like to be a beta tester?

[loglow]

@loglow, dunno if you saw this thread: https://forum.pjrc.com/threads/58943...port-to-RT1062 but it may be useful for your bringup. Also might increase the addressable market for your board, with the CircuitPython version possibly not needing the teensy chip.

Yes, this is very cool. I'm pretty sure at this point that the Teensy bootloader chip will be optional.

I've just picked up an LPC-Link2 board (aka Embedded Artists EA-XPR-200, only costs $20) for future (hopefully successful) programming purposes.

[loglow]

Here's an update!

A new revision is all routed up and ready to go.

I stuck with my previously-posted layout and overall size of 14.5 x 25.5 mm:



Here's the current pinout:



The bottom now has 11 small test pads for use with a pogo pin fixture:



The fixture has a header for a SWD/JTAG cable (in the absence of a Teensy bootloader) and a USB-B port for interfacing with a Teensy bootloader (if one is installed).

The first assembled fixture will be ready very soon, and I hope to have a couple assembled boards to test by the middle of February. Obviously these boards won't have the bootloader chips populated since they're not yet available. The fixtures should be pretty cheap to build and will probably cost less than $50 each, perhaps significantly less.

I hope to be able to program these boards using the LPC-Link2.

[blackketter]

Looking good! Do you have a mechanical drawing or some dimensions for a footprint?

Also, what's the timeframe for a beta?

[Edward]

This is great!
I've often thought about this sort of thing as much as I love the teensy's, I really don't care for 0.1" header as I'm almost always dropping them on a PCB. Personally I'd want a bootloader and a USB because most of my work requires a USB for comms, but you can leave these off the module. Anyone who can use this module should be happy enough to add the bootloader/USB themselves, and actually I also like having the choice of connector to suit the application. I'm also 100% on board (yes, pun intended) with castellations, as previously said because you can reflow them or use an Iron. You also get the bonus of easily visually inspecting the solder to check it's good, which those of us using hacked toaster ovens for reflow (or is that just me?) value.
Talk to us about beta!

[wcalvert]

This looks really great, I will be keeping tabs on development. It seems like everything hinges on bootloader support to make it viable for production use.

[lastshaman]

Hi Loglow,

what a fantastic idea!
I was about to write a post asking the community for suggestions about the post-development phase, the one in which, after using the T4 for speeding up development, the time comes of putting the MiMXRT1062 on the final PCB.
In most cases, as in mine, for example, after the chip is put on the production-ready board, there is no need to flash the code using the Arduino IDE (or PlatformIO or whatever) anymore.
Is your design open-hardware or do you plan to sell them?
I'm certainly interested in the schematics, PCB layout and BOM. How many layers does your layout have?
In case you need a beta tester, I could even have a couple of your boards produced and provide feedback.
Let me know.

[ecurtz]

Thanks! Perhaps you'd like to be a beta tester?

Probably not until there's a version with the bootloader, but I'll keep close tabs on your progress and see if I have the time to commit for it to make sense earlier.

[joey120373]

I think this is a great idea and long overdue, I would buy them. If this ends up turning into a real board, I would think a teensy 3.2, 3.5/6 and an LC board would be a great idea also. A small, thin .8mm castellated teensy 3.2 / LC would be super handy for all kinds of things. Fist thing that comes to mind is thin small form factor LCD TFT backpack boards.