GDB-compatible Debugger for the Freescale Coldfire MCF52235CAL60 V2 Ethernet Processor

[Randy Yates]

Hi Folks,

I've been searching for a device like this and have only located one
thus far, the Abatron BDI3000. However, at $2600, this is outside my
budget.

Does anyone know of a less expensive debugger that meets these
requirements? The goal is to put together a toolchain involving it,
Sourcery's gnu toolchain for the device, and Eclipse. So the key is
requirement is that it must be compatible with Eclipse's debugging
interface.

Other information I have found on the subject:

1. Called P&E and verified that the USB-ML-CFE (shipped with the Coldfire
M52235EVB) does not support gnu debugging.

2. Called Segger about their JLink debugger and found it doesn't support the
Coldfire processor, mainly just the ARM processors. Nor do they have one
that does.

PS: Note that the Freescale Coldfire utilizes the BDM debug interface.
--
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

[Jack]

Randy Yates <ya...@digitalsignallabs.com> wrote:

> Does anyone know of a less expensive debugger that meets these
> requirements? The goal is to put together a toolchain involving it,
> Sourcery's gnu toolchain for the device, and Eclipse. So the key is
> requirement is that it must be compatible with Eclipse's debugging
> interface.

Why not use directly the Freescale Toolchain (that is based on Eclipse)?

Bye Jack
--
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

[Anders....@kapsi.spam.stop.fi.invalid]

Randy Yates <ya...@digitalsignallabs.com> wrote:
> I've been searching for a device like this and have only located one
> thus far, the Abatron BDI3000. However, at $2600, this is outside my
> budget.

PEEDI from Ronetix matches the specs, but it is in the same price range
as Abatron's device.

There are a number of open-source BDM interfaces (eg. OSBDM from P&E[1],
USBDM[2]), but they are pretty much only supported with CodeWarrior.
TBLCF, the originator of all these open-source interfaces, had some
degree of support in the BDM tools[3] package, but AFAIK it hasn't been
maintained in a long while.

-a

[1] <http://www.pemicro.com/osbdm/>
[2] <http://usbdm.sourceforge.net/>
[3] <http://sourceforge.net/projects/bdm/>

[Randy Yates]

pip...@disney.com (Jack) writes:

> Randy Yates <ya...@digitalsignallabs.com> wrote:
>
>> Does anyone know of a less expensive debugger that meets these
>> requirements? The goal is to put together a toolchain involving it,
>> Sourcery's gnu toolchain for the device, and Eclipse. So the key is
>> requirement is that it must be compatible with Eclipse's debugging
>> interface.
>
> Why not use directly the Freescale Toolchain (that is based on Eclipse)?
>
> Bye Jack

You mean the one that costs $5000?

[Randy Yates]

Randy Yates <ya...@digitalsignallabs.com> writes:

> pip...@disney.com (Jack) writes:
>
>> Randy Yates <ya...@digitalsignallabs.com> wrote:
>>
>>> Does anyone know of a less expensive debugger that meets these
>>> requirements? The goal is to put together a toolchain involving it,
>>> Sourcery's gnu toolchain for the device, and Eclipse. So the key is
>>> requirement is that it must be compatible with Eclipse's debugging
>>> interface.
>>
>> Why not use directly the Freescale Toolchain (that is based on Eclipse)?
>>
>> Bye Jack
>
> You mean the one that costs $5000?

...and that only runs under Windoze?

[Randy Yates]

Thanks much, Anders, for these specific references!

[tim.....]

"Randy Yates" <ya...@digitalsignallabs.com> wrote in message
news:87d2bfm...@digitalsignallabs.com...

> Randy Yates <ya...@digitalsignallabs.com> writes:
>
>> pip...@disney.com (Jack) writes:
>>
>>> Randy Yates <ya...@digitalsignallabs.com> wrote:
>>>
>>>> Does anyone know of a less expensive debugger that meets these
>>>> requirements? The goal is to put together a toolchain involving it,
>>>> Sourcery's gnu toolchain for the device, and Eclipse. So the key is
>>>> requirement is that it must be compatible with Eclipse's debugging
>>>> interface.
>>>
>>> Why not use directly the Freescale Toolchain (that is based on Eclipse)?
>>>
>>> Bye Jack
>>
>> You mean the one that costs $5000?
>
> ...and that only runs under Windoze?

Dunno about the first part, but if it's based upon Eclipse why would it only
run under windows?

tim

[Tauno Voipio]

Eclipse is not the whole show. It is using other tools, like compiler,
assembler, linker and debugger, which all need to run under the OS
with the Eclipse setup. Any of the necessary tools may be sufficient
to ruin running under something else than Windows.

--

Tauno Voipio

[Randy Yates]

tim,

I'm just going by what they say on their site. As Tauno said, it's
probably because one or more of the components (e.g., the compiler
toolchain, or even more likely, the driver for the debugger) only runs
under Windoze.

[Jack]

Randy Yates <ya...@digitalsignallabs.com> wrote:

> pip...@disney.com (Jack) writes:
>
> > Randy Yates <ya...@digitalsignallabs.com> wrote:
> >
> >> Does anyone know of a less expensive debugger that meets these
> >> requirements? The goal is to put together a toolchain involving it,
> >> Sourcery's gnu toolchain for the device, and Eclipse. So the key is
> >> requirement is that it must be compatible with Eclipse's debugging
> >> interface.
> >
> > Why not use directly the Freescale Toolchain (that is based on Eclipse)?
> >
> > Bye Jack
>
> You mean the one that costs $5000?

The special edition is completely functional and free (until 64KB of
compiled code for the Coldfire).
At a certain point (last time I checked was 6 month ago),there was a
version for Linux, but it seems that there isn't anymore.

[David Brown]

(I don't have any secret information from Freescale here - this is just
what I have understood from tool availability, forum posts, etc.)

Freescale CodeWarrior (Eclipse version) used to run under Linux, but
support was dropped several versions ago. There was never any clear
explanation given - my guess is that some PHB went cost-cutting based on
figures of the moment rather than trends and predictions. It is not
uncommon for testing and support to cost more for a Linux port, simply
because there is a much wider variety of Linux distros and setups, and
the user base was smaller than for Windows (I heard figures of 15-20%).
They also quoted figures showing that many who downloaded the Linux
version also downloaded the Windows version (I certainly did that - like
many places, we have a mixed environment and it is good practice to
download releases for multiple platforms at the same time) - so they
"reasoned" that Linux users could just switch to Windows. This is
despite the growing trend for technical people, such as embedded
developers, to drop Windows as fast as Windows is dropping them (we want
operating systems, not overgrown telephones).

There were no good technical reasons for the decision to drop Linux -
almost all the parts were fully cross-platform (the editor, the
debugger, both CodeWarrior's own compiler and the gcc ports used for
several targets, most wizards and "beans", and even P&E's debugger
interface). There were a few parts that were not included in the Linux
version, but nothing important.

As for the $5000 price tag, that's basically for C++ support. (It's
actually for the full "professional" version, but as that's the only
version with C++, the C++ support is the main reason for buying it.)
This is something that has always annoyed me with CodeWarrior. For
small or medium projects, the free size-limited version is often fine -
but if you want C++, it's $5K. I can well understand that they want to
make a bit of money from professional tool users, though the main
purpose of CW is to help sell Freescale chips, but this jump is a bit steep.


Freescale have now changed this philosophy considerably for their
Kinetis line. The new Kinetis Design Suite is free of charge on Windows
and Linux, with debugger support for OpenOCD and P&E Micro, C and C++
(just gcc - they have dropped their own compiler), and lots of other
goodies.

Unfortunately for you, Coldfire is a dead-end architecture. Freescale
haven't killed it yet - they tend to continue support for a long time
after a family has left the mainstream. But they only have room to
concentrate on two architectures - ARM and PPC. And it is the ARM users
that are growing, and where they need good, cheap, cross-platform tools
to compete with other ARM vendors (especially in the Cortex-M space).

[Randy Yates]

David,

Thank you for this thorough discussion. As it turns out, I proposed a
Kinetis K60 as an alternative based on other considerations (basically,
more MIPS, more memory, and less $$$) during the proposal phase of this
project, but they shot it down because "they already have a basic system
running on the V2." I sensed the dead-end of the Coldfire (I think it's
basically a 68K with some special peripherals, no?), and really didn't
want to work on this processor. I also don't like the looks of the \
uTasker OS they're using, but I admittedly know little about it.

<beat head against wall>

[David Brown]

On 02/09/14 13:57, Randy Yates wrote:

> David,
>
> Thank you for this thorough discussion. As it turns out, I proposed a
> Kinetis K60 as an alternative based on other considerations (basically,
> more MIPS, more memory, and less $$$) during the proposal phase of this
> project, but they shot it down because "they already have a basic system
> running on the V2." I sensed the dead-end of the Coldfire (I think it's
> basically a 68K with some special peripherals, no?), and really didn't
> want to work on this processor. I also don't like the looks of the \
> uTasker OS they're using, but I admittedly know little about it.
>
> <beat head against wall>
>

The Coldfire was a complete from-scratch re-implementation of the 68k
ISA. At the time it was designed, the 68k was a well-loved ISA, widely
supported by tools, OS, and other software. Many people still consider
it the best designed ISA ever to be used in mainstream processors. But
the 68k family were getting long in the tooth - there were lots of
inefficiences, it was hard to take advantage of newer cpu features, and
the existing cores were big, slow, and power-hungry. So Freescale made
a few modifications to the ISA (such as to cut out the more complex
addressing modes and to add a few new instructions), then made a modern
cpu core family design using up-to-date ideas and covering a number of
size/power/cost/performance points (the v1..v4 cores). The result was a
rather elegant cpu - the Coldfire has a very nice core and ISA, is power
and space efficient, and can be implemented in modern high-density
microcontrollers.

The only problem is that Freescale was competing with itself with the
PPC core, the M-core (remember them?), their DSP cores (especially their
hybrid core), and their newly licensed ARM cores. For a good while,
Coldfire had a solid place in the market - for several years it was the
top choice for NAT routers and it was the key reason for the existence
of ucLinux (now the MMU-less architectures in mainline Linux). But MIPS
stole the small network market, and ARM7 and later Cortex M took the
high-end microcontroller market, and Freescale's own PPC was a better
choice for high-end networking and automotive. Coldfire found a new
niche in a family of low-power devices that were pin and peripheral
compatible with a family of 8-bit devices - letting users design the one
board and choose low-end or high-end cpu cores. But there is nothing
Coldfire can do there that can't be done cheaper, faster, and
lower-power with Kinetis Cortex M4.

Coldfire isn't going anywhere. It is not going away, but it is not
getting any (significant) attention from either Freescale or third
parties. But as long as you are happy with what you have got, and don't
need a path to bigger/faster/smaller/cheaper future devices, then it is
a solid if unexciting choice.