Teensy MK20DX256 - in circuit debugger or programmer

Status
Not open for further replies.

Brendon Shaw

Active member
I have a project which I would like to move from Arduino IDE to the mbed enviroment and just wondering if anyone could recommend any in circuit debugger or programmer which I could use? There seem to be so many on the market and should looking for some recomendation.
 
With mbed I would use one that supports CMSIS-DAP. Some of the low cost (like $15) Freescale boards allow you to separate the CMSIS-DAP programmer/debug interface from the main ARM MCU. Then the former can be used with an external MCU (edit: I understand that some are locked to the same MCU as the Freescale board - not so useful).

You can also use mbed to create a .hex file and load it into a teensy with the teensy programmer.
 
Last edited:
Most of us use the JTAG replacement: SWD. It's just 3 wires. To use SWD on Teensy, you have to cut traces on the board so that you can temporarily or permanently get the SWD, SCLK plus GND and Vcc to wire up to an SWD debugging pod. There are cheap and expensive SWD pods. I use a $25 one made by an NXP/freescale competitor and china clones. It might work on the Freescale, since SWD is based on an ARM Cortex standard.

The IDE is the issue... support for the chosen SWD pod. Not for commercial use, there's the free light version of IAR, or Keil. Free version is 32KB size limited on code. PRo versions of these are costly. As a professional, I use IAR. Next best, IMO, is Visual GDB. $99. Includes support for SWD. Others include Rowley (IDE for GCC) and Atollic (Eclipse IDE for GCC).

SWD is so very nice to use, with real breakpoints and so on.

Teensy doesn't allow SWD without the cut traces mod - which has been photographed and posted here.
I hope a future T3 will allow SWD debugging via some PCB jumpers or 0 ohm options or some such.
The TRACE option in SWD needs one more pin.

SWD has flashing of course.
 
Thanks for all the information, I have to say I am still confused but starting to understand more. May I need to go on a training course or lot of reading on the processor and development platforms.
 
Thanks for all the information, I have to say I am still confused but starting to understand more. May I need to go on a training course or lot of reading on the processor and development platforms.
You can start by using Ardino's IDE and Teensyduino from here. Then if you use Windows, you can stay with Arduino and get a much better IDE free from Visual Micro. It uses Teensy board files.
Then you can add hardware breakpoint debugging on a modified Teensy board, as in post #3.
 
I've had good experiences with mbed. Also, no problems with loading teensy programs into hardware designed for mbed. So I expect that the reverse (loading mbed programs into the teensy) works fine.

If someone wrote a gdb-stub/target-gdb* for teensy, I'd say good enough and forget about modifications or other setups.

* - this is code that you link into your program that would allow gdb to debug the teensy - no SWD hacking or separate debugging interface needed.

I'm curious - why do you want to move from the teensy (software and/or hardware?) to mbed?
 
Last edited:
I've had good experiences with mbed.
Probably because I was an early adopter of the NXP 1768 based mbed when that was the only target supported. The IDE was OK. They had very few libraries and library management was immature. But I and so many others struggled with the TCP/IP stack for the '1768 which was very buggy- unusable. A year later it still was. It was a volunteer adaptation of lwip. I presume that by now they have something for most targets. The dual MCU on the original mbed board was at the time amazing - slightly similar to Teensy 3. Copy executable to the simulated USB flash storage, reboot, and it ran the youngest such file. It was my first experience with this sort of thing.

I've not used mbed for other targets.
 
Does anyone have any specifics as to which debugger they use with MK20 processors? Does anyone have openocd working fully (with flash)?

Unfortunately, it looks like gdbstub, a software solution that is probably most appropriate for a teensy 3, isn't going to happen.

The proprietary games most of the adapter manufactures play is obnoxious. This makes the open source blacksphere/blackmagic probe interesting.
 
In the rare cases I need it, I just use the following:

1: Teensy 3.x as JTAG interface.
2: OpenOCD
3: DDD graphical interface to GDB.
 
Interesting. Can you tell use more - source code for program on the teensy? Exact .cfg file used with openocd?
 
If you don't mind windows, there's Visual GDB. Low cost though not free. Uses SWD. Excellent.
 
Last edited:
I have used a ST-LINK V2 + openocd. $4 on ebay. I'm afraid to try loading a program with it (ie, erase/write flash).
 
https://github.com/xxxajk/TAGme
But don't expect it to work out of the box.
You have to hack OOCD for it to work...
I have that too, and can privately share that part with you (source).
It is not the latest OOCD, and there could be some issues as well... However it works for me.
 
I have used a ST-LINK V2 + openocd. $4 on ebay. I'm afraid to try loading a program with it (ie, erase/write flash).
Doesn't Freescale have their own equivalent to ST-Link ($21 for an ST-branded one) ? That USB based SWD debug and flasher is a great thing.
And does Freescale have a free DFU software tool and an optionally enabled BOOT ROM (not flash) in their M0-M4's? Like ST's where the boot automatically detects/uses USB/DFU, UART1, UART3, I2C, CAN?
I've looked but am still unsure.
In the ST ARMs, and Freescale too? - one can fab the board with the BOOT ROM disabled via an MCU pin (that can be inaccessible) on the board. But software can use the ARM memory remapping registers to remap the BOOT ROM to address 0 as if the jumper was in place, then jump to the boot. I've done that as an "emergency" way to get to the ROM BOOT when a distribution of firmware has an overlooked bug that bricks the board after it goes to non-technical users. This is triggered by jumpering the UART1 TX,RX together but re-config them as GPIO OUT/IN and then toggle the GPIO OUT and read the input put, to detect the jumper is in place and force a jump to boot, from application startup code that assuredly runs ever power up, despite a fault app. Saves one's buns when, say, a 3rd party library like FATFS hangs due to file system corruption. (And using the watchdog timer is another backup for this).

Of course, PJRC has to use the add-on chip for downloading as an anti-counterfeit means, else China, Inc. would overtake in a nanosecond.
 
Last edited:
One thing I dislike about the commercial units is the firmware isn't open source.
That is why I rolled my own out of the Teensy3.1, well, that and it supports Paul's efforts a little bit.
I still need to get the rest of it going or hand the project off to an interested party.
There is a lot you could do with the code, including gang programming for mass production.
Sky is the limit when you got the source code.
 
I agree, "limited to" seems to be a favorite phrase with commercial debug adapters and software (although you often find out the hard way). And there are way too many standards. So support open source solutions like IBDAP-CMSIS-DAP + (pyOCD or Open OCD). Or the Black Magic probe (which could be ported to run on a teensy).
 
Last edited:
I tried flashing a new .bin with a st-link v2, open ocd and a MK20DX256. I got nothing but "could not erase" errors. Has anyone succeeded with this?

A J-Link + open ocd worked fine.

I have a P&E Multilink I could try, but I understand that their gdb-server is Windows only.

I ordered a IBDAP-CMSIS-DAP - moving to open source standards.

Versaloon also looks interesting, but I don't see a source for a dongle.

This sounds like the lowest cost open source solution (just add a $4 STMF103 from ebay): https://github.com/devanlai/dap42

Or similar idea, load CMSIS-DAP firmware into a $4 ST-LINK V2 adapter: https://mvdlande.wordpress.com/2015/10/05/cmsis-dap-on-a-cheap-st-link-v2-mini-adapter/
 
Last edited:
Status
Not open for further replies.
Back
Top