I have mentioned in MCU10.2 released a new feature in CodeWarrior: support for the USB Universal Multilink FX from P&E Microcomputer Systems. Two Multilink FX arrived last week at the University, and finally I had my hands around it. The first thing which came to my mind when I saw the picture of the device on the P&E website: the black boxes are back!

Can I hope for a “Special FX Edition” in that box with cool sunglasses and a flash stick to erase and reprogram FLASH memory of microcontrollers? That would definitely make the flash erasing and programming easy and fast, as in the movie. 🙂
Why bother about the speed? I presented in CodeWarrior Tool Tip #2 multiple ways how to flash a device. It shall be easy, and it shall be fast! If you download say 60 times a day your program, and if you could make it faster by a minute, then you will have to wait one hour less. Drinking coffee all the waiting time might not be healthy neither.

As a starter, the unpacking of the FX was fast and easy:

But it comes with one Multilink FX device, CD, technical summary documents, and lots and lots debugging adapter cables. Is supports S08, RS08, S12(X), HC16, DSC, 683xx, ColdFire V1/V2/V3/V4, Power Architecture MPC55xx/56xx/PX and Kinetis.
Wow! It supports the HC16 for which I wrote one of my first compilers! Wondering if my old board still works and if I would be able to get up and running? Something for next time.

Let’s add the FX to the family of Multilinks I have. At the Lucerne University of Applied Sciences and Arts, the ‘brown’ USB Multilink are used in labs and classes a lot. Kind of our debugging working horse here. Used in many projects for Freescale S08; but as well for S12 and ColdFire V1, as they all use the same BDM interface. With using more and more 32bit cores like ColdFire and Kinetis, we have added the green USB Universal Multilink to the list of devices. The Universal Multilink has a great concept: it allows you to use the same debugging device for multiple architectures: from 8 to 16 to 32bit; for BDM and for JTAG. So one debugging device for a wide range of microcontrollers.

USB Multilink (brown, left), USB Multilink Universal FX (black, middle) and USB Multilink Universal (green, right)The CD comes with documentation, drivers and firmware updater. CodeWarrior for MCU10.2 installs already the drivers, so you do not need to install anything (but you can). In CodeWarrior, the FX works seamlessly like any of the Multilinks. If you switch from one architecture to another (say from S08 to ColdFire or Kinetis), then the firmware gets automatically updated. The ‘green’ Universal Multilink already has the same feature.

If you connect the FX to the host, the device gets enumerated and shows up as Multilink Universal FX Rev A in the debug configuration of CodeWarrior:

In this dialog the FX supports a debug shift speed up to 25 MHz. Selecting a speed higher than supported by the microcontroller might report the device as secured (see for Kinetis below), or fails at connect.

Another difference in the hardware: The FX is able to power a target board with 3.3V or 5.0V (up to 200 mA according to the data sheet). You enable this with a jumper accessible with opening the ‘connector door’. A target power cable less on my desk, I love that :-)! I Need to try this out next week.

Time to visually inspect the hardware and compare it with the other Multilinks: Many of the concepts of the previous devices you can find in the FX: It is using the same Freescale S12UF32 microcontroller responsible for the USB connection as in the other two Multilinks. The FX has a CPLD (marked below) from Altera which likely is responsible for the performance in the FX.

Time to check out the performance: At the University, beside of the Multilinks, we are using the OSBDM/OSJTAG with the Freescale Tower boards: it is free, open source, but know as not very fast. Different from the S12UM32 in the Multilinks, the OSBDM/OSJTAG is using a S08JM60 as debugging device.
I’m going to compare the download performance: OSBDM/OSJTAG vs. Multilink Universal vs. Multilink Universal FX. I did not include the ‘brown’ Multilink as it would supports not the same range of processors.

The benchmark is downloading code/data to FLASH. The the time is hand-stopped from pressing the ‘debug’ button to the time when it stops in main(), using CodeWarrior MCU10.2. Because there is initial overhead by eclipse and the debugger to launch the debug session, I’m using a small application as the baseline.

First benchmark is using the S08MM128 Tower board:

This uses an 8bit S08 microcontroller with a BDM debug interface. The Tower board includes the an on-board OSBDM debug interface using the S08JM60.

The following table shows the download time measured. The last line shows the the calculated flashing speed with the largest code size, subtracted the overhead measured with the smallest download size. E.g. for the OSBDM this is (98 kByte – 0.1 kByte)/(83 s – 15 s) = 1.4 KByte/s.

Results for TWR-S08MM128 (FLASH):

Code Size	OSBDM	Universal Multilink	Universal Multilink FX
0.1 KByte	15 s	10 s	10 s
18 KByte	27 s	13 s	13 s
32 KByte	37 s	14 s	14 s
64 KByte	59 s	17 s	17 s
98 KByte	83 s	22 s	21 s
KByte/s	1.4	8.2	8.9

The result for the S08: The data shows no real difference between the FX and the normal Multilink. This is in alignment with what P&E says on their web page. So if I use an S08, it does not matter if you use an FX or a normal Multilink. But using a Multilink cuts download time by a factor of 2 to 4 compared to OSBDM. My coffee consumption goes down!

Next test target is the TWR-MCF52259 board. I pick this one as I use it in my embedded system programming lecture and lab:

It has a ColdFire V2 core on it, and has a similar OSBDM circuit on the back with the S08JM60. I created a project with the New Project Wizard in MC10.2. Measuring the OSBDM download speed showed a disappointing 2 KByte/s :-(.

So need to look into this rather slow speed. Flashing for the ColdFire V2 is special in CodeWarrior: it is using a Target Tasks instead letting the debug probe firmware (e.g. OSBDM/OSJTAG or Multilink) doing this.

The Target Tasks are very flexible and powerful (see CodeWarrior Tool Tip #2), but the same time they could be counter productive. I would expect that download performance would get at least slightly improved for V2 if the firmware in the debugging device would take over. Similar to what is implemented for S08 or Kinetis. That way the flashing process would be close to the target CPU instead controlling it from the host. Anyway…

I know that I have seen better performance, and indeed: I missed to disable ‘verify’:

It is debatable if I should keep verify enabled or not. To my knowledge ‘verify’ is always performed by the Multilink. It would be good if there would be an option for the user to decide if he wants and needs verify? For myself, I always switch off ‘verify’ in the Target Task for OSBDM and ColdFire V2 because it has such a big impact. Simply check the table:

Results for TWR-MCF52259 (FLASH):

Code Size	OSBDM		Universal Multilink		Universal Multilink FX
	verify	no verify	verify	no verify	verify	no verify
3 KByte	32s	30 s	26 s	26 s	25 s	24 s
40 KByte	49 s	40 s	34 s	28 s	33 s	26 s
130 KByte	95 s	72 s	60 s	38 s	52 s	34 s
234 KByte	147 s	107 s	89 s	50 s	76 s	43 s
KByte/s	2.01	3.00	3.67	9.63	4.5	12.2

Results: The green Multilink is about 3 times faster than OSBDM (with no verify), and the FX is about a factor 4 faster. The advantage of the FX might come from the increased Debug Shift Speed possible: I was able to get it increased to 1.79 MHz compared to the 1 MHz in the Universal Multilink:

This again reduces my amount of coffee every day if I use a Multilink. Still, I would have expected a bigger improvement using the FX for the MCF52259 Tower board? Factor of 4 compared the OSBDM is a good thing, but maybe more would be possible?

I have contacted P&E with my preliminary measurement: As always, their support was very responsive and useful. They confirmed that for MCU10.2 with S08/CFV1/RS08 the performance is very similar between the Multilink Universal and Multilink Universal FX. The MCF52259 does not show big performance improvements because the default clock rate is so slow, that the FX is running pretty close at the speed of a regular Multilink. With faster MCF52259 or other ColdFire I should be able to see much better performance improvements. Unfortunately I do not have another V2-V4 board right now available, but this is something to follow up.

Next I’m using the Kinetis TWR-K60N512 board:

This board has an ARM Cortex-M4 on it, and it is using JTAG instead of BDM. The OSJTAG is provided by the same circuit and S80JM60 as on the other Tower boards from Freescale.

I was able to get the Debug Shift Frequency up to 12.5 MHz. A higher speed did not work for me (it reported the device as secured):

And here the FX can show the performance:

Results for TWR-K60N512 (FLASH):

Code Size	OSJTAG	Universal Multilink	Universal Multilink FX
1 KByte	31 s	13 s	13 s
68 KByte	47 s	16 s	14 s
135 KByte	64 s	18 s	15 s
270 KByte	98 s	23 s	16 s
504 KByte	157 s	33 s	20 s
KByte/s	4.0	25.2	71.9

Result: The FX is up to 10 times faster compared to the OSJTAG, and about factor 3 faster than the ‘normal’ Universal Multilink. The larger the code size, the better. As applications for the Kinetis tend to get larger and larger, this really makes a difference. And greatly reduces my level of coffee consumption :-).

So the results are promising, and it looks like even for S08/CFV1/RS08 there might be an additional performance boost possible in the future if P&E follows with updated firmware and drivers. I will try my TWR-MCF5441X (which should show better results than the TWR-MPC52259) and will post the results. And I have as well a DSC Tower board I could try.

Summary:
OSBDM/OSJTAG is OK for small binaries, and if you can afford it do wait (depends on the price for coffee at least).
The Universal Multilink provides better performance and is a good fit if you develop mainly for S08 and want to have faster download and debug speed.
The Universal Multilink FX is a must have if you develop large size applications for ColdFire and Kinetis.

I hope that data is useful. I’ll see if I find time to work with other boards. For sure I need to check out the FX with another ColdFire board…

Happy FX’ing 🙂