Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 13 of 13

Thread: Teensy 4.0 - how to connect a jtag debugger ?

  1. #1
    Junior Member
    Join Date
    Aug 2019
    Posts
    6

    Teensy 4.0 - how to connect a jtag debugger ?

    I found this article extremely interesting

    https://mcuoneclipse.com/2017/04/29/...swd-debugging/

    where it is shown how to use Teensy 3.5 / 3.6 with a jtag debugger like the Segger J-link
    But the signals available on the Teensy 4.0 are slightly different
    I consider the limitations imposed by the Arduino ide too restrictive and therefore I would like to understand if it is possible to use these cards with the classic emulators / debuggers that are on the market
    Has anyone already addressed the problem of connecting a jtag / swd debugger on the brand new Teensy 4.0, and could it share its work?

  2. #2
    Senior Member
    Join Date
    Aug 2016
    Posts
    128
    its not possible I think. I dont think the relevant signals are brought out from the chip

  3. #3
    Junior Member
    Join Date
    Aug 2019
    Posts
    6
    I think that if E14 (tms), F12 (tck), F13 (mod), F14 (tdi), G13 (tdo), G10 (trstb) pin are exposed, like visible on schematic diagram, a jtag connection with debugger, technically, may be realyzed
    The only unknown is the G10 signal which could be connected to pin K3 in a way that is not accessible (under the cpu pins) and therefore cannot be modified
    But all other signals, by removing or isolating the MKL02Z32VFG4 chip, are accessible

  4. #4
    For another thread concerning why some people want to use the full GCC, GDB, debug adaptor and SWD debug connection to the Teensy 4.0, see:

    https://forum.pjrc.com/threads/57340...Atmel-Studio-7

    I have an inexpensive debug adpator which will work with GDB etc. under MCUXpresso, the LPC-Link2:

    https://www.nxp.com/design/microcont...-link2:OM13054

    I have never used it, so I have no experience with SWD debugging, or with the trace facility it can also provide with one more pin from the ARM chip (as best I understand it). I have not yet received my Teensy 4.0. Here is my understanding of how it could be done.

    First, the documents I have referred to. The Teensy 4.0 schematic:
    https://www.pjrc.com/teensy/schematic.html

    NXP's eval board, which contains the exact same 1062 MCU as the Teensy 4.0:

    https://www.nxp.com/design/developme...MIMXRT1060-EVK

    At the bottom of that page is a link to the schematics. On page 5 these show the two signals we need for SWD debugging (maybe we need more, I don't fully understand all this):

    MCU pad E14 = JTAG_TMS == SWD_CLK.
    MCU pad F12 = JTAG_TCK == SWD_DIO.

    I haven't yet figured out what would need to be done to the Teensy 4.0 to get its 1062 MCU operating with SWD debugging. I have not yet read the debugging section (pages 185 to 191) of the 3637 (!!!) page Reference Manual IMXRT1060RM:

    https://www.nxp.com/products/process...ine=Data-Sheet

    These two SWD signals, by their JTAG names, are available in two connectors of the MIMXRT1060-EVK: Firstly on the 20 pin 2.54mm black header J21 "JTAG" (page 12) and secondly on the small 10 pin 1.25mm header J34 "JTAG CONNECTOR". J34 is towards the top right of the MIMXRT1060-EVK, just above the crystal. This, I assume, is where the little ribbon cable from the LPC-Lind2's J7 "Target SWD/JTAG" would plug in.

    I will probably get MIMXRT1060-EVK and figure out SWD debugging with it, before attempting to do the same with the Teensy 4.0.

    Plan A would be to remove the MKLO2 chip with a hot air gun and invoke Superman powers in order to solder wires to its pads, which connect to the corresponding pads on the 1062 MCU:

    MKL02-5 -> MCU-E14 == SWD_CLK.
    MKL02-8 -> MCU-F12 == SWD_DIO.

    Assuming there was no problem removing it, and assuming there was a way of getting the 1062 MCU into SWD debug mode, this should work. The only difficulty is that then I can't use the Teensy loader software, via a PC (or Mac or Linux box, in principle) via a USB lead, to install the firmware file I intend to create.

    (I assume there is a way of getting whatever firmware I create with GCC into the file format required by the Teensy loader program: https://www.pjrc.com/teensy/loader.html . I haven't investigated this - can anyone point me in the right direction?)

    So I would need to unplug the SWD-modified Teensy from my prototype board and plug in an ordinary Teensy. This would be OK, and might be the best approach.


    Plan B would be to achieve the same results without removing the MKL02, by resetting it, and then by super-hero soldering to its pins 5 and 8, without melting all its pins and so having it come off the board.

    In the Teensy 3.6, this can apparently be done by grounding MKL02-15. In the Teensy 4.0 this is connected to MCU-F3 = EMC_01. That could have one of many functions, depending on the ALTx mode.

    Looking up the MKL02Z32VFG4 pin functions, the Reference Manual: https://www.nxp.com/products/process...umentation_Tab and data sheet "Kinetis KL02: 48MHz Cortex®-M0+ 8-32KB Flash (16-32 pin)" . . .

    Signal RESET_b is the hardware reset input. On page 37 of the data sheet, this signal is on pin 15 by default, and in ALT3 mode. In ALT0 mode pin 15 has no function. In ALT2 and ALT3 modes it has functions other than RESET_b.

    I guess that the way the MKL02 is used in the Teensy 4.0 uses ALT2 or ALT3, and the RESET_b signal cannot appear on a pin in any other way - so I guess that the MKL02 can't be reset. If so, then this clobbers Plan B.


    It will be a lot of work to understand the 1062 MCU, starting with the deciding what combinations of functions can be assigned to the pins which the Teensy 4.0 makes accessible, either as pins around the side or as pads underneath to which wires could be soldered. I haven't yet tried to do this regarding the functions I want to use, but for now I assume there will be a way of doing what I want while using SWD debugging, and perhaps tracing, arrangements.


    Plan C would be to abandon the idea of using the Teensy for development. Then, I would use the MIMXRT1060-EVK with some special wiring arrangement so it would plug into my development board (and the final product's PCB in the future) just as I would plug in the Teensy 4.0. I am expecting to have to modify the Teensy 4.0 with some extra wires to the underside pads, with and some kind of extra connector which plugs into the product's PCB.

    This is all a lot of fuss, but it would be worth it not to have to worry about surface mounting these tiny BGA devices, and to have the end-user USB firmware installation arrangements already totally sorted.

  5. #5
    Here is Plan A approach: Modify the Teensy 4.0 so we can plug an LPC-Link2 directly into it. This involves removing the MKL02 with a hot air gun and soldering to some of its pads (0.5mm spacing) with fine enamel wire. I would use a stereo microscope and, instead of a normal soldering iron tip, such a tip modified with an extension made of a small tip of wire, such as wire-wrap wire, which will be the actual tip to heat the enamel wire near its end where it solders to the pad. There will be no need to actually touch the pad with this tip, since the enamel wire will melt it perfectly well.

    Get a 10 pin 1.27mm spacing box header to suit the little IDC cable which comes with the LPC-Link2, e.g. Samtec TFM-105-02-S-D-WT or
    FTSH-105-01-L-DV-007-K. This is SMT, so solder it to an SOIC adaptor board, ideally one with 2.54mm spaced holes in rows 15.34 (0.6") apart. Then, four of these outer holes, electrically isolated from the SMT pads, could be used for mechanical mounting using thick wires extending vertically from four of the outer row of Teensy pins.

    Following the way the ten pins are used in the MIMXRT1060-EVK, the non-signal connections on the left row are:

    01 - 3.3V. (Potentially connected to the Teensy's 3.3V supply.)
    03 - GND.
    05 - GND.
    07 - NC.
    09 - NC, though it is GND at the LPC-Link2, and so can be here too.


    Pin 10 is active low reset. In the MIMXRT1060-EVK this goes through a buffer or level-translator chip and various jumpers to drive the 1062 MCU's pad M7, POR_B. So this is where it needs to go in the modified Teensy 4.0, where it is normally driven solely by MK0L2 pin 9.

    This connection, along with the four signal connections, needs to be like this. The 1st pin number is that of the header. The 2nd is the MKL02 pad number. The 3rd item is the 1062 MCU's ball ID. The 4th is the MCU's ball's default function (page 89 of the datasheet). In brackets is an alternative name given to the same net in the MIMXRT1060-EVK schematics.

    02 5 E14 JTAG.MUX.TMS (SWD_DIO)
    04 8 F12 JTAG.MUX.TCK (SWD_CLK)
    06 6 G13 JTAG.MUX.TDO
    08 7 F14 JTAG.MUX.TDI
    10 9 M7 POR_B


    The other two MCU balls of interest are:

    F11 SRC.BOOT.MODE[0] Driven solely by MKL07 pad 4.
    G14 SRC.BOOT.MODE[1] Grounded.

    These inputs have 100k pulldowns. They select how the 1062 MCU boots after reset. In the Technical Manual page pages 199 onwards describe the options. If F11 is low (open) then "Boot from Fuses" is selected. If it is driven high, the boot mode is "Serial Downloader". I assume we want the latter, so I think we need to tie MKL02 pad 4 to +3.3V.

    This is all from reading the doco. I have no experience with these matters, and so would appreciate any comments.

  6. #6
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,330
    Quote Originally Posted by Robin Whittle View Post
    Here is Plan A approach: Modify the Teensy 4.0 so we can plug an LPC-Link2 directly into it. This involves removing the MKL02
    So what you are saying, is buy a Teensy and modify it to a NON_TEENSY. (IMO, a Teensy is only a Teensy if it has the Bootloader chip)

  7. #7
    I explained my reasons for doing this in https://forum.pjrc.com/threads/57340...Atmel-Studio-7 . In summary, I want to use GCC, GDB and so proper debugging to develop firmware for products to be sold to other people. The Teensy 4.0 provides extraordinary compute power of the type I need, for a very attractive price, with no need for me to worry about BGA surface mounting, quality control and testing. This would be enough reason on its own to prefer buying Teensy 4.0 devices and plugging them into my PCB, rather than surface mounting the 1062 MCU itself.

    The second reason, also probably good enough on its own, is that the Teensies all have a robust, easy to use, multi-OS USB-based system by which my customers can install the latest firmware I release.

    The Teensy arose in an Arduino environment and the mass market this entails enables the development costs to be spread very thinly per actual Teensy sold.

  8. #8
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    531
    Did this with a T3.6 using VisualCode (the IDE I'm developing with anyway) and the CortexDebug extension. Works without any problems. I removed the bootloader chip connected the two JTag signals, and program the board via the JTAG programmer. Should work the same with a T4. Directly soldering at the tiny boodloader pads might be difficult but should work. Here a quick demo:

    https://youtu.be/EFDhgXoOHLc

  9. #9
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,556
    Quote Originally Posted by Robin Whittle View Post
    Here is Plan A approach: Modify the Teensy 4.0 so we can plug an LPC-Link2 directly into it.
    .........
    would appreciate any comments.
    Here's a few random bits of info which might help...

    All Teensy 4.0 are fuse configured for JTAG signals, TCK,TMS,TDI,TDO, so plan on those 4 pins. SWD protocol using only 2 wires isn't supported. The fuse setting is irreversible, so it's impossible to use SWD.

    The IMXRT chip has 2 completely different JTAG controllers (ARM debug vs boundary scan + NXP proprietary stuff), selected by a MOD signal. Make sure you connect that pin for the one you want.

    If you try boundary scan, there is a bug inside the chip were everything locks up if you remain in certain boundary scan states for too long (approx 8 seconds). Return to the test idle state if you're going to delay.

    If you remove the MKL02, you'll need to connect some sort of voltage monitor reset circuit to drive PSWITCH+TRST high after the 3.3V power is stable. The chip will not work (reliably) if you just tie those signals high. The R-C delay circuit NXP recommends is a bad idea, as we discovered during the beta test. Teensy 4.0 has a pulldown resistor on that signal. You need to drive it high for the chip's DCDC converter to turn on and power up the CPU (with 1.15V by default). Steady logic high does not work (despite the words in NXP's reference manual suggesting it should). A low-to-high edge on PSWITCH is required to get the DCDC converter to turn on.

    If you turn off the power, or use the On/Off button to turn the 3.3V regulator off, be aware that driving any pin high can feed enough phantom power through the ESD protection diode to keep the SNVS portion of the chip powered up.

    Some chips allow JTAG to access the CPU while reset is asserted. IMXRT isn't one of them. If you have a debug script which does things like put the core into halt mode and configure vector traps before releasing reset, it definitely will not work.

    Attempting this plan won't be easy, but hopefully these tips can save you from the most frustrating issues which aren't well documented anywhere... other than this forum message!

  10. #10
    Hi Paul,

    Thanks very much for your reply.

    As far as I know, SWD with a debug probe / adapter such as the LPC-Link2 is the only way to program and debug the RT1062 MCU with GCC and GDB.

    Assuming this and ". . . it's impossible to use SWD." I will pursue Plan C: Adapt the MIMXRT1060-EVK so that a connector system plugs into the prototype board, and later any product board, in the same way as the T4 will plug in. The details are to be determined, since this depends on how many pins I will be mounting on the T4.

    There may be some fundamental differences between the T4 and the MIMXRT1060-EVK. For instance, the Flash chips are different. There are two options on the EVK, one of which has the same pinout as the 2MB W25Q16JVUXIM used in the T4, the 8MB S25WP064AJBLE. However, I guess that this would not be important, since the exact type of Flash storage wouldn't affect how the firmware runs. All that matters is that GCC etc. can produce a hex file representing the code which works on the EVK, where that hex file can be read by the Teensy loader program on a PC, Linux box etc. The T4 in operation is really just the RT1062 chip with a subset of pins made available. The EVK is the same, though it does have some extra chips which I won't be using, such as the SDRAM.

    I would need to look closely to see that all the MCU pads which the T4 makes available are also available on the EVK. I assume, for now, that I will be able to do what I want with whatever the T4 makes available.

    BTW, there's a typo in the T4 schematic. The MCU pads which drive the USB socket are M8 and L8, rather than M7 and L7.

  11. #11
    Plan D is like Plan B, but the RT1062 chip is removed and a new one, with no fuses blown, is reflowed in its place. Some info on the MAP-BGA package:

    https://www.nxp.com/docs/en/application-note/AN4982.pdf

    I should be able to get this done locally by a large SMT assembly company. I don't know whether they would have the required stencil, or whether a stencil would fit. I understand that the alternative to a stencil is to use a solder paste dispenser.

    This would be more expensive but less work than making a Teensy-like adaptor with wires going to an MIMXRT1060-EVK. More importantly, it would be a real Teensy, with its power supply, Flash chip and and other attributes, without noise, capacitance, crosstalk etc. which would inevitably result from some kind of adaptor arrangement. Such problems could be especially troubling for high speed signals and ADC accuracy.

    I would need extra circuitry to drive the POR_B (M7), DCDC_PSWITCH (K3) and AD_B0_11 (B10 = JTAG_TRSTB in ALT0). Using the now-removed MKL02 for this would probably be the best approach.

    I do not yet understand the various ALTx settings. It is early days for me hunting and pecking through the 3.6k page reference manual.

    I have ordered a MIMXRT1060-EVK so I can learn about debugging with MCUXpresso and the LPC-Link2 before attempting to do this with a modified T4.

  12. #12
    Just adding myself into the thread to see progress...

  13. #13
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,330
    Quote Originally Posted by Robin Whittle View Post
    More importantly, it would be a real Teensy
    I would doubt that, Teensy is registered by PJRC and if PJRC blows fuses, then IMO a Teensy 4.0 would need fuses blown. at most it Teensy 4.0 alike.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •