Teensy 4.0 - how to connect a jtag debugger ?

A

amorosik

Member
I found this article extremely interesting

https://mcuoneclipse.com/2017/04/29/modifying-the-teensy-3-5-and-3-6-for-arm-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?
 
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
 
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-Teensy-4-0-is-programmable-debuggable-with-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/microcon...c-microcontroller-utilities/lpc-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/developm...evk-i.mx-rt1060-evaluation-kit: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/proces...60?&tab=Documentation_Tab&linkline=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/proces...0-plus-core:KL0x?fpsp=1&tab=Documentation_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.
 
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.
 
Robin Whittle said:
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
Click to expand...
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)
 
I explained my reasons for doing this in https://forum.pjrc.com/threads/57340-Teensy-4-0-is-programmable-debuggable-with-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.
 
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:

 
Robin Whittle said:
Here is Plan A approach: Modify the Teensy 4.0 so we can plug an LPC-Link2 directly into it.
.........
would appreciate any comments.
Click to expand...

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! ;)
 
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.
 
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.
 
Better than "fine enamel wire" is 30 gauge kynar insulated wire designed for wire wrapping (an ancient ritual almost forgotten). It can be stripped to expose a very short length of wire and with good technique the insulation won't deform.
 
Robin,
You wrote:

"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."

Segger J-Link comes with a GDB server. Are you sure lack of SWD is a show-stopper for everybody, or is it just a show-stopper for you? Not trying to be contentious, just trying to establish options. I was simply stunned to find the debug pins unusable, but I'm an absolute Teensy newbie and finding this thread has been wonderful.
 
Hi Pete,

Most Teensy 4.0 users don't need SWD since they are happy to program it via Arduino. The lack of SWD debugging is only a problem for people such as me who want to use normal, full-function, GCC, C++17 or whatever, GDB and suitable IDE (MCUXpresso). I am planning CPU-intensive, audio DSP and real-time control, while driving a small OLED display. I wouldn't want to do this without a robust, modern, C++ compiler and every debug capability I can get my hands on.

I have not yet actually got this going, even with a Teensy 3.6 which I did modifiy for this purpose, due to not actually needing the capability right now. This is a longer term project. However, I read all about it. There is also a trace facility in these ARM MPUs and I think a way that the LPC-Link2 and IDE (MCUXpresso) can support this. I recall it is a method of real-time streaming parts of the internal state of the chip to the outside world, where it can be displayed and analysed as part of the debug environment. This sounds really valuable to me, and would be a significant step beyond normal GDB debugging in the exact same CPU that GDB is running on, such as with x86-64 PCs.

After the discussions about the difficulty of modifying the Teensy 3.6 for SWD, and the revelation that it was a feature which was planned all along but not implemented (https://forum.pjrc.com/threads/42728-Debugging-strategies/page3 msgs 61 & 62) I was expecting there would be no need to modify the 4.0 for this.

The Teensy products and the very large and enthusiastic user-base which supports them have a background entirely based on Arduino. As far as I know, Arduino has grown into a multi-microcontroller (8, 16 and 32 bit, with various completely different architectures) development system by which a somewhat C++ like compiler with a particular IDE arrangement can be used to program these devices via a USB port, using a bunch of relatively standardized C++-like libraries. Also, I think, there is some kind of standard subset of pins so I/O boards "shields" can be plugged into an Arduino compatible main board, with little regard to which kind of MPU is on it. As far as I know, it is then possible to cobble together various libraries, source code from other people and your own source code, compile and actually have things run properly. I have no idea how this could be achieved, with all the vagaries of compilers, MPUs, pin configuration etc.

The result is an entry-level MPU development system with very low cost, which runs on any platform (Windows, Linux or whatever, even ARM Linux I guess) which enables people to maintain their source code and have it run on even more powerful, and completely different MPUs, than whatever they started with some years ago.

However, as best I understand it, Arduino debugging is limited to inserting printf() statements in the code to report activity. I assume there is some single step debugging facility with breakpoints, but I have never looked close enough at Arduino to know.

Anyway, the existence of this extraordinarily compact and cost-effective Teensy 4.0 is entirely a result of this Arduino user base for actual Teensys, and beyond this, the broader Arduino user base who would be attracted to applying all their skills, effort and source code to new projects with the Teensy 4.0. So the design is optimized for Arduino. There are surely very good reasons it can't support SWD debug - and Paul explained why above. He needed JTAG control of the 1062 and this could only be done by blowing a fuse on it.

Paul kindly explained some other tricky things which I would need to do to get SWD debugging working, apart from installing a 1062 without the blown fuse.

My one, so far, Teensy 4.0 is currently awaiting a company to attempt the BGA removal and reflow, also removing the MKL02. There's no guarantee it will work, so I may try a few more in order get at least one working.

I should soon have an MIMXRT1060-EVK and will fire it up with MCUXpresso and the LPC-Link2 so I can properly learn how it all works with GCC and GDB.

Then I will attempt to achieve the same thing with the modified Teensy 4.0. The FLASH chip is different than that of the MIMXRT1060-EVK, but perhaps this won't matter much or at all. WMXZ, above, wrote that this would be a Teensy-alike - and indeed this is true, since this particular board would be incapable of loading firmware from USB using the Teensy loader program (Windows or Linux) or running under Arduino. However, in terms of running my firmware, it would be a real Teensy 4.0 in all other respects, with connections, capacitance, FLASH chip and everything else.

By then I will have some more Teensy 4.0s and the next step would be to establish how to use GCC to generate a hex file suitable for the Teensy loader software (Windows or Linux) to program my project into a normal Teensy 4.0. I should be able to unplug my SWD Teensy 4.0 from the prototype main board, plug in the normal Teensy 4.0, do the USB boot load operation and see my firmware run exactly as it does when I am developing it with GCC, GDB and MCUXpresso.

In order to be able to do this easy plug in swapping, I have had Samtec make (for very low cost, including just a few dollars for DHL courier!) the precisely defined pins and sockets needed for this. See https://forum.pjrc.com/threads/57122-Teensy-4-0-Breakout-Kit?p=216537#post216537 . I haven't mounted these yet, since they would get in the way of the BGA reflow operation. It will report my progress here, but it may be a few months before I work on it properly.

If I can't get this going, then Plan B would be to use the SDK with ribbon cables, as short as possible,with grounds between the signal lines, to a little board with the same pin arrangement as a Teensy 4.0 (most easily done with a Teensy 4.0 with its components removed). That would plug into my prototype board for debugging. Theoretically it would work, but there would be extra cable capacitance, crosstalk, inductance, ringing etc. which could easily make development much more difficult, such as with ground noise, ADC input slew times and high-speed drive of the OLED display and other devices.
 
Robin Whittle said:
There is also a trace facility in these ARM MPUs and I think a way that the LPC-Link2 and IDE (MCUXpresso) can support this.
Click to expand...

For tracing you need also need a SWO pin, the 1050/1060 M7s do have SWO.

I have a 1050 EVK and the SWO is not available on the debug header and you have to grab it on GPIO_B0_13 which is SW7 pin 2, also you need to pinMux it:

IOMUXC_SetPinMux(IOMUXC_GPIO_B0_13_ARM_CM7_TRACE_SWO,1);

They might have fixed this on the 1060 EVK you are thinking of getting.
 
AndyCap, thanks very much for this. I looked at the schematics of the MIMXRT1060-EVK and the same seems to be true. This is bit 13 of the LCD interface: GPIO_B0_13, solder ball D10.

D10 is accessible on the Teensy 4.0, via pin 12 of the MKL02, which will be removed.
 
> Arduino debugging is limited to inserting printf() statements in the code

I have some concerns about a lot of programmers having no exposure to a sometimes very useful tool.

Conceivably gdbstub could be used instead of a hardware debugger. Or if one had some particularly tough problem, one could put the code on a MIMXRT1050-EVK to debug.

As always, kudos to Paul for being open and helpful.
 
Debug probe using JTAG rather than SWD?

Just because I wrote a lot of words here should not be taken as an indication that I know what I am doing. A post today by Paul made me even more aware of my lack of knowledge in this field, so I would really appreciate anyone's attempts to enlighten me.

I have never written a line of code for a Teensy or for any ARM MCU. I have never used an SWD or any other kind of hardware debug adaptor. I have never used MCUXpresso. I have never used Arduino - and all I know about it is that it doesn't support the use of a debugger. I have long known JTAG ~= Boundary Scan as a means of setting and reading registers inside a chip, with a single clock cycle to step the chip through a single operation, but I have never used JTAG in any way.

Paul's post was in response to a thread which started in March 2017 about how to connect a debugger to the Teensy 3.5/3.6: https://forum.pjrc.com/threads/42728-Debugging-strategies?p=222275#post222275 Since it is pertinent to the current thread, I am quoting the full text here. (I hope this is OK - I couldn't find a way of private messaging him about this.)

PaulStoffregen said:
The ARM Cortex-M7 debug features are exactly the same with JTAG as they are with SWD. Lack of support for SWD doesn't mean you can't connect a debugger. It merely means your debugger needs to speak JTAG protocol and connect with 4 or 5 signals instead of only 2 signals.

If you have a SWD-only debugger, you'll need to get one which uses JTAG protocol.

NXP designed the IMXRT chip to make JTAG and SWD mutually exclusive. Why they did it this way, I do not know. They could have made it switchable between these 2 on-the-fly, as they did with Kinetis. They could have put a JTAG-AP inside the chip on the DAP bus, to make the JTAG-only stuff accessible by SWD (and they could have put the very nice Kinetis MDM-AP into this chip, but sadly did not). They could have used a pin to somehow configure which protocol is used, similar to the boot config pins. But NXP did none of these things. For reasons I do not know, NXP made the chip so only 1 protocol is used, controlled by an OTP fuse bit.

Some important features are only available in JTAG mode, especially boundary scan. We use boundary scan for the 15 sec restore process. It's also used for testing the pins on a bed-of-nails test fixture. Since boundary scan is impossible to access when the chip is configured for SWD, we must configure Teensy 4.0 for JTAG.

The absence of SWD doesn't mean you can't connect a debugger. It only means you need to use a debugger which speaks JTAG protocol rather than SWD protocol. If you remove the MKL02 chip or otherwise modify the hardware to access the signals, you simply need to connect to 5 signals (TMS, TCK, TDI, TDO, MOD) instead of 2 (SWDIO, SWCLK). The JTAG MOD pin can be tied to GND if you wish to only access ARM debug, so you only need 4 signals.

If your ARM debugger is SWD only, this is the time to stop complaining and start shopping for one which speaks JTAG protocol.
Click to expand...

My (so far only) Teensy 4.0 has had its MCU replaced by a fresh one without any fuses blown. I had the MAPBGA reflowed by a company who just did some SMT assembly for me. I guess the reflow is good, but the only way will be to test it - and now, of course, it can't be run via the Teensy boot loader. It will be some time before I attempt to connect the debugger.

I use GCC and GDB for C++ on AMD64 Linux with the Codelite IDE. As far as I know, this is unique among IDEs in that three things are true: Firstly, Codelite uses the original text-mode method of talking to GDB, the same one humans use. Some other IDEs use a later, non-human-readable, interface which is apparently more efficient. Secondly, Codelite makes all its communications with GDB available on a debugger console ("Output" tab). This means I can use a watch to view a potentially large (26k recently) range of doubles in a C array or vector or whatever and can collect all the values for further analysis by copying and pasting text from the console. (Such large numbers are impractical to view in the watch window, but it can be handy - and it requires sending GDB a command to turn off its sanity limits on listing large numbers of items: set max-value-size unlimited . I added this to Codelite's GDB startup commands.) Thirdly, I can use the console to type commands to GDB and see the results.

This combination of features is extremely useful to me. Some years ago I tried Eclipse and NetBeans and neither could do all these three things. So I expect that with MCUXpresso I won't be able to give GDB commands manually or copy and paste GDB's responses to the IDE's commands.

Maybe, once I am up to speed with debugging and MCUXpresso I will find it advantageous to switch to Codelite but for now I assume that I would continue using MCUXpresso.

My current plan is:

1 - Wait for the MIMXRT1060-EVK to arrive. https://www.nxp.com/design/developm...evk-i.mx-rt1060-evaluation-kit:MIMXRT1060-EVK .

2 - Follow the Quick Start guide: https://www.nxp.com/document/guide/:GS-MIMXRT1060-EVK with MCUXpresso (on Windows 7). The guide mentions virtual serial ports and PuTTY, so it seems that the application, running in the 1064 MCU, can drive serial data to a terminal program on the Windows machine (PuTTY in my case). I looked at this guide's videos today. It seems that the EVK contains a "DAPLink CMSiS-DAP" debug probe, which is part of the first class of possible probes MCUXpresso can work with: "MCUXpresso IDE LinkServer (inc. CMSiS-DAP)". The other two classes are "P&E Micro" and "SEGGER J-Link". I have no clear idea what these things are, and for now will not investigate further. From this second video I can see that GCC is used to compile the code, but I am not sure that GDB is being used.

3 - Connect my LPC-Link2 to the EVK and do whatever is required in MCUXpresso to create a Hello World, LED blink or similar project, with all the desired pin configurations for the 1062 MCU and this particular EVK, for compilation by GCC and debugging via GCC. So in this setting, the EVK is powered but not connected via USB to anything.

4 - Remove the T4's MKL02 and modify it to connect the LPC-Link2, (msg 5) including resolving questions about power on reset as mentioned above by Paul (msg 9). Attempt to get the same or similar demo project to load and debug with the T4 instead. There might be various problems here - for instance the Flash memory chip of the T4 is different from that in the EVK, but perhaps they behave the same way (msg 10).

5 - Expand the code to do something fancier.

6 - Try to get tracing going. I have only read a little about this, and will read more when I actually have the gear set up. As best I understand it, the ARM chip can be configured to repeatedly report various items via the trace pin, and there is some way of getting this through the debug probe to MCUXpresso which will analyse and display it in real-time. I imagine this would be extraordinarily useful.

7 - If, for some reason, I wanted to try to replicate all this with Codelite, maybe there is a way of doing this - so giving me the ability to give commands directly to GDB, which as far as I know is not possible with MCUXpresso. If so, I would still want the trace facility, so perhaps there is some way of acheiving this with other software, or with MCUXpresso. I guess there's a way I could write my own trace analysis software and so adapt it to analyse whatever particular events in memory or IO ports were giving me grief.

8 - Figure out how to make GCC create a hex file which can be loaded into a normal T4 with the Teensy loader program. Then, my prototype board would have sockets for pins mounted on a normal T4 or a debug probe modified T4, using connectors around the edge and internally. (See msg 81 https://forum.pjrc.com/threads/57122-Teensy-4-0-Breakout-Kit/page4). I would develop with GCC, GDB and hopefully real-time tracing. The future product would use sockets to accept a standard T4 with added pins. Future customers would be able to use the Teensy loader to install new firmware. My impression is that this very user-friendly and absolutely bulletproof in that the boot loader firmware, in the MKL02 can never be overwritten.

This 8 point plan is pretty far over the horizon since at present I have no direct experience with any of this stuff.

I had assumed that the SWD protocol was the only way of attaching a debug probe - specifically the LPC-Link2, which struck me as a very cost-effective and highly developed (NXP and Embedded Artists) debug probe compared to some of the older alternatives which were the only way of doing this a few years ago.

With Paul's message quoted above and after re-reading AndyCap's msg 16, I think that the LPC-Link2 can do both SWD and JTAG protocols. From Paul's message I tentatively think that it would be possible to connect the LPC-Link2 to the T4 using the JTAG protocol, rather than the SWD protocol. If so, to the best of my knowledge, there would be no need to remove the 1062 and replace it with a fresh one without any fuses blown. However, amorosik (msg 3) mentions that one of the signals needed for JTAG is not accessible on the T4.

I ordered two more T4s.
 
Robin Whittle said:
However, amorosik (msg 3) mentions that one of the signals needed for JTAG is not accessible on the T4.
Click to expand...

TRST is not required.

Virtually all JTAG debuggers will pulse TRST low, and then also drive 5 clocks on TCK with TMS high to reset the TAP controller. Odds are very slim you'll find any debugger which uses only TRST and doesn't do the 5 clocks to get the TAP to test logic reset state.

I have never used Arduino
Click to expand...

8 - Figure out how to make GCC create a hex file which can be loaded into a normal T4 with the Teensy loader program.
Click to expand...

Perhaps you should spend a little time to actually use Arduino+Teensyduino, even if only for testing & comparison if you run into subtle problems. Even if the Arduino IDE doesn't give you all the features you want, certainly it can be used to just compile and run the many known-good examples (which you'll find in the File > Examples menu after you select Teensy 4.0 in the Tools > Boards menu).

From Arduino, click File > Preferences - Show verbose output during [ ] compilation to cause Arduino to show you the exact command lines it uses to compile your code. You'll see it runs gcc *many* times. The first set are with "-E" (pre-process only) which are used to discover which libraries your program actually uses. Even through the commands look similar, those ones with "-E" aren't actually compiling anything.
 
I sometimes wish I had a proper debugger - adding print statements (or pulsing a line) feels so last century. If cared more, I'd order a MIMXRT1060-EVK and load it with binaries compiled with the teensy 4 IDE. But I eventually get the bugs out without doing this.
 
2 MKLO2 pins un-accounted for?

PaulStoffregen said:
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! ;)
Click to expand...

Paul,
I am also very interested in connecting a JTAG debugger to the T4.1 (just purchased 2 of them) and this info is very helpful. But looking at the schematics there are still 2 pins connected to the MKL02 un-accounted for: B0_13 and EMC_01. If the MKL02 is removed what needs to be done to these 2 pins if anything? From the RM EMC_01 can be muxed to JTAG_DE_B but i've never heard of that signal as a standard JTAG singnal? Also, sorry if this is a dumb question but I'm just curious as to why you can't just use the built in Serial Downloader to program the Flash instead of going to all the bother to use the MKL02? I'm new to this part and the RM is rather daunting even though I'm a retired EE with 30+ years experience in embedded SW & HW I can't figure out how the Teensy loader info gets from the USB to the MKL02 so it can be programed to the Flash through JTAG? Although I think I understand how the ROM bootloder can be controlled by manipulating the boot configuration signals through the MKL02. I also note that the SWD pins of the MKL02 are brought out but unconnected, so I assume one could still use SWD to replace/debug code on the MKL02 if one desired? If any of this info is proprietary to PJRC forgive me but any info you can share would be helpful.
Thanks, John Kennedy
 
After further thinking my preference would be to leave the MKLo2 in place to manipulate the PSWITCH properly for a power on reset and the config signals for bootup, but to modify/replace the code so the usb loader still works but add an additional mode that allows JTAG debug by tristating the required JTAG pins so they can be accessed externally by the debug probe. I'm not sure all this would be possible. With my past experience my platform of choice is Xilinx Zynq parts, but the least expensive Zynq dev boards are $100+ and for small projects just not economically justifiable and Ardunio is just too wimpy. So my search for a cheaper alternative lead me to Teensy. These IMXRt 1062 parts are amazing and T4.0, T4.1 are quite inexpensive. But I need a real IDE (not arduino) with a real debugger, since many projects I work on are quite complex and using primitive debug techniques is just too time consuming. Would it be possible to sign an NDA with PJRC to obtain additional info for my personal use only, for continuing this research? Thanks again and any help greatly appreciated.
John
 
You must log in or register to reply here.
Back
Top