Performance Zone is brought to you in partnership with:

Erich is Professor at Lucerne University of Applied Sciences and Arts and Distinguished Member of Technical Staff at Freescale Semiconductor. Erich has a MsCS degree and 18+ years of experience in the embedded software and tools world. He created many embedded cross C/C++ compilers and debuggers. Additionally he is researching in the domain of programming languages, real time and mechatronic systems. Erich is a DZone MVB and is not an employee of DZone and has posted 119 posts at DZone. You can read more from them at their website. View Full User Profile

Debug External Processors with USBDM and Freedom Board

05.02.2013
| 3871 views |
  • submit to reddit

Teaching at a university means to work in a very special environment. What students love is ‘Open Source’: because it allows them to ‘see’ things and learn from the technology. The other thing is: students have a low budgets, so they appreciate if they can use inexpensive or low-cost hardware and software. The FRDM-KL25Z Freedom board for sure meets that low price, and no extra programming device needed.

Now they are building their own boards, and they wish to program and debug it. They can borrow the Segger J-Links and P&E Multilinks we have available at the university. But why not use the Freedom board as ‘hobby’ debug and programming solution? As explored in “Using the Freedom Board as SWD Programmer“, they can use the default factory installed OpenSDA to program another microcontroller of same type. But not to debug it.

While writing the ”Using the Freedom Board as SWD Programmer” article, I was looking into USBDM. USBDM has added in January 2013 support for OpenSDA. But at that time, it was somehow not working for me, and I had not enough time to find out what the problem was. Time to get that fixed. Good news: With help and tips from the USBDM community, I have it finally working :-)

USBDM Debugging another FRDM-KL25Z

USBDM Debugging another FRDM-KL25Z

USBDM is a free open source (GPLv2) debugging/programming interface for a range of Freescale microntrollers.

Note: USBDM is *not* OSBDM. OSBDM (or OSJTAG) is an older ‘free’ debugging interface present on many of the Freescale Tower Boards.

It currently supports CodeWarrior and CodeSourcery Eclipse. With it, I wanted to overcome the OpenSDA limitation and using it as general purpose debug/programming device with CodeWarrior for MCU10.3.

:idea: USBDM comes with a standalone flash programmer and scripting engine. But I had not had the time to look into that (yet).

Installation

The installer is available for download from http://sourceforge.net/projects/usbdm/files/Version%204.10.4/Installation/ (USBDM_4_10_4a_Win.msi).

USBDM_4_10_4a_Win.msi

USBDM_4_10_4a_Win.msi

:!: Initially I had used the USBDM_4_10_1_Win.msi (the one without the ‘a’. It worked at the beginning, somehow I ran into connection problems later on. Note sure what has caused this, maybe the problem I describe at the end of this post. So I decided to go with a fresh MCU10.3 (b121211), installed the USBDM_4_10_4a_Win.msi, and since then things are working ok.

The setup provides the flexibility only to install what is needed:

USBDM Setup

USBDM Setup

:!: In above dialog, I need to verify/specify the path to my CodeWarrior installation.

I would have expected that this would install the drivers for me too. Maybe it does, but it did not work for me. What I had to do is download the USBDM_Drivers file (USBDM_Drivers_1_0_1_Win_x64.msi for my Windows7 64bit machine) from http://sourceforge.net/projects/usbdm/files/Version%204.10.4/Installation/ and to install it.

USBDM_Drivers for Windows

USBDM_Drivers for Windows

:!: Not sure if this was just a problem with my machine, but: afterwards my OpenSDA/OSBDM/OSJTAG device drivers did not enumerate properly. I had to browse to the driver files e.g. in C:\Freescale\CW MCU v10.3\Drivers\P&E\Drivers\osbdm to have them installed again.

OpenSDA USBDM Firmware Installation

For OpenSDA, I need a special firmware. I did download the USBDM_OpenSDA firmware zip file:

USBDM_OpenSDA Firmware

USBDM_OpenSDA Firmware

Then updated the firmware on the Freedom board, following the instructions in the OpenSDA.txt in the archive. After that, the device should enumerate properly as “USBDM BDM Interface”:

USBDM BDM Device enumerated

CodeWarrior for MCU10.3

If everything is working out, you should have now an extra connection setting in the ‘new bareboard project’ wizard:

USBDM in the new project wizard of CodeWarrior

USBDM in the new project wizard of CodeWarrior

:!: I don’t know why, but for whatever reason this option and the corresponding functions (debug connections) were not showing up in CodeWarrior first. Since I tried it the first time (and it did not work), I have for sure rebooted my machine. Fact is: it is working now :-) . So if you see the same issue, maybe a reboot or re-running the setup will help.

To verify that things are properly installed, I can check the plugin using the Help > About dialog, then press ‘Installation Details‘ button:

USBDM Debug Connection Plugin

USBDM Debug Connection Plugin

It adds a new Connection Type to the CodeWarrior debugger: USBDM ARM Interface

USBDM ARM Interface

USBDM ARM Interface

:idea: It is very easy to switch between the original OpenSDA and USBDM: simply ‘USBDM ARM Device’ from that drop-down box.

By default, it has set up a connection speed of 1.5 MHz: I was able to increase it to 12 MHz and that worked fine:

USBDM Connection Speed

USBDM Connection Speed

Using USBDM as SWD Debugging Probe (FRDM-KL25Z to FRDM-KL25Z)

To use USBDM on FRDM-KL25Z to debug another external processor, following is needed

  1. Having a 10pin ARM Cortex Debug (SWD) header populated on two boards
  2. Connecting the two boards with a 10pin flat cable
  3. Having J11 cut on the ‘master’ board to disconnect the SWD clock from the resident processor
  4. No change needed on the ‘slave’ board to be debugged.

And indeed: this worked :-) : I’m able to use my USBDM to debug the other KL25Z Freedom board:

Two boards hooked up for debugging

Two boards hooked up for debugging

FRDM-KL25Z debugging FRDM-K20D50M

Debugging the FRDM-K20D50M with the FRDM-KL25Z the same way as debugging the the FRDM-KL25Z above:

FRDM-KL25Z debugging FRDM-K20D50M

FRDM-KL25Z debugging FRDM-K20D50M

As above, the ‘master’ boards needs to have the J11 trace disconnected.

Using FRDM-KL05Z to Debug an External Board

Next one is the FRDM-KL05Z. However, this did not work out of the box. Until I have found this post in the Freescale Forum: The problem is a wrong wiring to the J6 header: the OpenSDA signal from U4 goes to pin1 of J6, and this pin1 goes as well to the KL05Z. This means that it is not possible to disconnect the OpenSDA from the KL05Z :-( . The solution is to cut a trace and connect it to either pin 4 of J1 (SWD header) or to pin2 of J1. I did the second solution.

First, I need to cut the J6 trace:

Cutting J6 Connection on FRDM-KL05Z

Cutting J6 Connection on FRDM-KL05Z

:idea: I always install a jumper afterwards so I can ‘undo’ the cut.

For the next step, a magnifying glass or a microscope is a good thing, plus some good soldering skills :-) : I need to re-route the Pin11 from U4 to Pin2 of J6. For this I need to cut the trace just before the via hole to the KL05Z:

Cutting Trace on FRDM-K05Z

Cutting Trace on FRDM-K05Z

After that, install a wire to route the Pin11 of U4 to Pin2 of J6:

Wire to re-route Signal

Wire to re-route Signal

:idea: Instead to Pin2 of J6, the signal can be routed to Pin4 of J1 instead. But J6 was much easier to do for me.

With this, the FRDM-KL05Z is prepared to debug an external processor:

  • With J6 removed, I can debug an external processor
  • With J6 installed, I debug the KL05Z processor on the FRDM-KL05Z board
FRDM-KL05Z debugging FRDM-KL25Z

FRDM-KL05Z debugging FRDM-KL25Z

Same way it works to debug the FRDM-K20D50M:

FRDM-KL05Z debugs FRDM-

FRDM-KL05Z debugs FRDM-

Note: I have not managed to debug the changed FRDM-KL05Z say from the FRDM-KL25Z or FRDM-K20D50M. I’m using a pre-production board here, so this might be the reasons. I can debug the other Freedom boards with the FRDM-KL05Z, just not the other way round. I have solved this problem, see “Debugging FRDM-KL05Z with USBDM“.

FRDM-K20D50M debugging FRDM-KL25Z

This time the FRDM-K20D50M hooked up to the FRDM-KL25Z: For this I have to cut/remove the jumper J11 on the FRDM-K20D50M:

FRDM-K20D50M debugging FRDM-KL25Z

FRDM-K20D50M debugging FRDM-KL25Z

Why a ‘professional’ Probe is a Good Thing: ‘bad’ FRDM-KL25Z Board

Then I tried it with another FRDM-KL25Z board: A student used that board in my class, and somehow managed to break the OpenSDA on it: it keeps staying in MSD bootloader mode, and cannot be debugged through OpenSDA.

So tried to debug that board with USBDM too, but I received “Failed to resume target process” error message:

Failed to resume target process

Failed to resume target process

I tried different powering (just in case) and even have cut the J11 and J3 to disconnect OpenSDA power and SWD clock:

Cut J3 and J11 Connection

Cut J3 and J11 Connection

But this did not help :-( .

However, with the P&E Multilink I’m still able to debug that board with the SWD debug header :-) . So there are definitely good reasons to use a probe like this: to recover from cases where USBDM cannot help. As always: as second source and backup is what an engineer always needs.

The other problem I was running into was this one with a 60 KByte application:

Failed to resume target process

Failed to resume target process

:!: Not sure if I have hit a limit, but after that I had to restart Eclipse to recover from this issue, as any other USBDM debug session failed. Maybe it has corrupted the DLL? In any case, I need to follow up on this.

Summary

With USBDM, I have an Open Source run control solution with CodeWarrior and the Freedom boards. So far I just have explored OpenSDA Freedom boards, but it should support boards and microcontroller beyond that: I can now download *and* debug other microcontroller with the Freedom board :-) . What I’m missing with USBDM is the USB CDC support which the original OpenSDA provides (or I have not seen how to enable that).

While ‘professional’ solutions like P&E and Segger worked for me out of the box, I had to invest time to get USBDM up and running. After that, it was working nicely. Spending that extra time is like with any other Open Source projects I did or used: I trade in time for less costs, or to learn new things on return. I hope that this article saves you some time and is useful for you.

Many thanks and kudos to pgo, dieter and Brion for their help and posts, and all the ones who developed USBDM!

Happy USBDMing :-)

Links




Published at DZone with permission of Erich Styger, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)