Men In Black are back! Flashing and FX’ing…

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:

FX Package Content

FX Package Content

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), USB Multilink Universal FX (black) and USB Multilink Universal (green)

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:

Seamless Debug Configuration for FX in MCU10.2

Seamless Debug Configuration for FX in MCU10.2

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.

Jumper to power the target with 3.3V or 5.0V

Jumper to power the target with 3.3V or 5.0V

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.

Hardware of USB Multilink (left), USB Universal Multilink FX (middle) and USB Multilink Universal (right)

Hardware of USB Multilink (left), USB Universal Multilink FX (middle) and USB Multilink Universal (right)

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:

TWR-S08MM128 Tower Card

TWR-S08MM128 Tower Card

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.

OSBDM S08JM60 Microcontroller on the backside of the TWR-S08MM128 board

OSBDM S08JM60 microcontroller on the backside of the TWR-S08MM128 board

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

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:

TWR-MCF52259 Board

TWR-MCF52259 Board

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.

Target Tasks View in CodeWarrior for MCU10

Target Tasks View in CodeWarrior for MCU10

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’:

52259 Target Task with Verify disabled

52259 Target Task with Verify disabled

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

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:

Multilink FX with 1.79 MHz Debug Shift Speed

Multilink FX with 1.79 MHz Debug Shift Speed for the TWR-MCF52259 board

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:

TWR-K60N512 Board

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):

FX Connection for the TWR-K60N512 with Debug Shift Freq of 12.5 MHz

FX Connection for the TWR-K60N512 with Debug Shift Freq of 12.5 MHz

And here the FX can show the performance:

Results for TWR-K60N512 (FLASH):

Code Size
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

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.

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 🙂

11 thoughts on “Men In Black are back! Flashing and FX’ing…

  1. Thanks for the comparison. I was seeing the same results with the 52259 with 8Mhz crystal for both the Multilink and Multilink FX. But I did see the improvement when I went to the K60 Tower board with the FX.

    I think your blog is great. Please keep providing entries like this to give more insight into the controllers and the tools.


    • Hi Mike,
      I was getting the performance improvement for the 52259 with increasing the debug shift in the debug launch configuration for it. See the image in “Multilink FX with 1.79 MHz Debug Shift Speed for the TWR-MCF52259 board”.
      If you keep it at the default 1.00 MHz, then indeed I have not seen much difference.


  2. Pingback: FatFs with Kinetis | MCU on Eclipse

  3. Pingback: Completing the FRDM-KL25Z Board | MCU on Eclipse

  4. Pingback: JTAG/SWD Debugging with the FRDM-KL25Z Board | MCU on Eclipse

  5. Pingback: Debugging ARM Cortex-M0+ Hard Fault with MTB Trace | MCU on Eclipse

  6. Pingback: Live View for Variables and Memory | MCU on Eclipse

  7. Pingback: First Steps with the P&E Tracelink | MCU on Eclipse

  8. Pingback: USB with the TWR-K60F120M and TWR-K70F120M | MCU on Eclipse

  9. Hi Erich,
    and thank you for the comparison. I wonder how FX vs normal performs for mpc56xx or mpc57xx architectures, do you know by chance? I might check PE for latest info too. Ciao, Lu


What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.