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 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.
USBDM comes with a standalone flash programmer and scripting engine. But I had not had the time to look into that (yet).
The installer is available for download from http://sourceforge.net/projects/usbdm/files/Version%204.10.4/Installation/ (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:
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.
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:
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”:
CodeWarrior for MCU10.3
If everything is working out, you should have now an extra connection setting in the ‘new bareboard project’ wizard:
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:
It adds a new Connection Type to the CodeWarrior debugger: USBDM ARM Interface
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:
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
- Having a 10pin ARM Cortex Debug (SWD) header populated on two boards
- Connecting the two boards with a 10pin flat cable
- Having J11 cut on the ‘master’ board to disconnect the SWD clock from the resident processor
- 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:
FRDM-KL25Z debugging FRDM-K20D50M
Debugging the FRDM-K20D50M with the FRDM-KL25Z the same way as debugging the the FRDM-KL25Z above:
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:
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:
After that, install a wire to route the Pin11 of U4 to Pin2 of J6:
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
Same way it works to debug the FRDM-K20D50M:
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:
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:
I tried different powering (just in case) and even have cut the J11 and J3 to disconnect OpenSDA power and SWD clock:
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:
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.
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.
- USBDM Version 4.10.4 announcement: https://community.freescale.com/thread/303257
- USBDM Documentation on SourceForge: http://usbdm.sourceforge.net/
- USBDM Project on SourceForge: http://sourceforge.net/projects/usbdm/
- USBDM Sources on GitHub: https://github.com/podonoghue
- USBDM/OSBDM discussion forum: https://community.freescale.com/community/bdm