Homebrew Coldfire Development

I can't vouch for the Coldfire, but most processors that use a JTAG or other BDM will let you burn flash from the BDM with degrees of effort that vary depending on the processor and the tools.

Often with processors like the Coldfire the design team will start with an evaluation board and use that as a reference design for the processor section of their board. You can usually do better than to copy the eval board's design, but it generally mostly works.

--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

Thanks Tim. Yes, I have looked at various designs and I think I can build the board (although all I can do home brew is 2 layer, I have read that the Coldfire works "better" with a 4 layer board with power and ground plane layers, but I havn't seen anyone say that it "Won't" work).

BDM is a possibility, I am trying to do this on the cheap and I have seen BDM designs on the Net that work with Linux, and software that supposedly works with the Coldfire BDM. So I may be able to do this.

The initial load of the part seems to be the only stumbling block that I forsee right now.

It would be neat if the part came with a simple loader in flash already, something that would work with s-records or whatever the modern equivalent is downloaded from the serial port. You could then easily flash your own, more capable bootloader (as long as you don't blow away the factory loader you could always "do over" if your program does not work correctly).

Unless I hear from anyone else I will plan on building the BDM interface and build a simple board and see if I can make it work.

Is there a better forum for a question such as this that anyone can point me to, maybe more specific to the coldfire ?

The biggest drawback that I have perceived (if my perception is incorrect someone please correct me) with the netburner board that I have is that they do not bring all of the address pins out to the expansion connector. If they did I probably could do everything that I want just using that board, expanding it any way that I would like.

If anyone else has any Coldfire bare chip load experience, please let me know !

Thanks ! Joe Simon WB2JQT

I gotta ask - What on earth are you talking about? The MCF5272 has 4K SRAM and no on-chip flash. Part of the reason for its big pin count is the need for external buses. (The 16KB of on-chip ROM is exactly that

- factory-programmed ROM with some data tables in it).

Therefore there are two normal routes for getting code into it (short of having a socketed flash chip and using an external programmer):

1. use the JTAG interface to manipulate the address/data buses directly and poke data into the external flash chip that way. REQUIRES that the development software knows your specific flash chip (since they have different write algorithms). This is not the easiest route.
2. use the JTAG interface to load a flashloader into on-chip SRAM and execute it. The flashloader grabs data from a serial port, Ethernet interface, SD slot, or whatever your board has available, and

Normally your first act would be to port a real bootloader like RedBoot to the platform, whereupon you no longer have to use the RAM flashloader to bootstrap the system - RedBoot can use whatever interfaces are available to load data to flash.

I don't know if that specific part also has a bootloader built into it, but even if it does it would still require that you write your own flashloader.

Is there a really good reason for using this chip? There are easier places to start - parts with on-chip flash for instance, are easier to homebrew (lower pin count, fewer interconnects to get wrong) and easier to develop for because they'll be directly supported by the development environment - one-click flash-and-run operation.

Hi Larwe,

Sorry, seems we have an impedance mismatch, I was thinking of using the

5282... From original message "I am interested in homebrewing a Coldfire MFC5282 microcontroller based system, ". The 5282 has 256k flash on chip, if I am reading the spec correctly. Maybe the confusion came in because I mentioned that I currenly have a Netburner board that uses a 5270, which does not have internal flash.

So, if I am correct, I could use the JTAG interface to write a minimal loader to internal flash OR to SRAM ?

I have never used JTAG, is that something within reach of a homebrewer ? As I stated earlier I want to try and do this on the cheap, because I think the Coldfire chip is pretty neat and I just want to see if I could get a minimal system (CPU, Serial Port RX/TX, Clock, reset logic, voltage regulation...). I see places that sell a JTAG cable for lesS than $20 US for parallel port connection and less than $40 FOR usb. I have however, never used JTAG and don't really know what else I need (software wise). Are there open source tools to do this ?

If I can get a minimal system going I could then decide if I want to put more effort into this to go further with my self education in this area.

Thanks for your input !

dada wrote in news:gkbl71$j7a$ snipped-for-privacy@news.motzarella.org:

Check out

This project provides support for the BDM on CPU32 and Coldfire including the MFC5282. You can build it for Windows or Linux. The project will work with gdb and with some effort Insight. On Windows I built gdb for the m68k (this support Coldfire) and linked it with the BDM library built from the above project.

You will not need any code in flash, but will need to initialize the MCU using a gdb command file.

Good luck with your project.

-Z

for the BDM on CPU32 and

project will work with gdb

support Coldfire) and linked it

a gdb command file.

Thanks Zevel, I will look into this

Joe WB2JQT

Forget JTAG - you want to use the BDM. Many of the ColdFire's do have a JTAG interface, but it is really only for real JTAG usage - very low level pin and connection testing, typically using rather expensive hardware and software for automatic board testing. When Lewin says "JTAG" in this context, he means "synchronous serial interface to an on-chip debug module" - for the ColdFire, that is the BDM interface.

As I say, forget JTAG. And even if the debugger interface were called JTAG, you couldn't use these cables - while JTAG is theoretically a standard, almost every microcontroller needs its own architecture-specific JTAG cable for debugging.

There are plenty of reasonably priced (not as low as $40, but certainly under $200) ColdFire BDM cables available, and a number of free designs if you search around. Parallel port versions will be cheaper than USB versions, but are much slower. As with any tool purchase, coordinate the hardware debugger choice with the software toolchain choice - a BDM cable that does not work with your software debugger is useless.

Also have a look at

for a gcc toolchain. These are the maintainers for the ColdFire gcc port, so they know what they are doing. They have entirely free versions, and subscription versions ($400, IIRC) that have extras such as more advanced debugger support, extra libraries, Eclipse integration, etc.

An interesting idea for your project could be to use a USB BDM cable combined with CodeSourceries "semi-hosting" libraries. These let your ColdFire software use standard C library file access functions through the BDM to the host PC (Windows or Linux). Your software can then read and write files on your PC's hard disk.

The part in question (the MCF5282) has flash on-chip. But there is no significant difference between using on-chip flash and external flash, you handle it the same way.

That method is, in my experience, very rare - unless you already have the software and hardware in place for JTAG-based card testing, it would be a huge effort.

When you say "JTAG interface" here, I presume you mean "synchronous serial interface to an on-chip debug module" - there are *many* different such interfaces on different architectures, with names like OCD, One-wire debug, BDM, etc. Even for those architectures like the ARM, AVR and MSP430 that call the interface JTAG, you are really talking about the bastardised proprietary enhanced JTAG interface that is used for debugging (a true JTAG test chain would be immensely inefficient for debugging).

It is certainly a common method to download a bootloader of some sort using the debug interface, and use that to download and program the application code from another interface. That's particularly useful if your program is large and the other interfaces are much faster than the debug link.

But you've missed option 3, which is probably the most common for small systems - use the debugger interface to download and install everything. You might or might not have a separate bootloader, depending on how you split the software and where you want to have the flash programming code. But downloading directly is particularly useful for debugging, especially if you have enough ram to run the program from ram. With a half-decent USB debugger cable, you'll get download speeds of 200-300K per second - an expensive Ethernet debugger will get at least ten times that if the target supports such speeds.

As for getting the software into the flash, there are a number of possibilities. Sometimes the development software will have direct support for flash programming, which can often be the easiest. Alternatively, it's not hard to write flash-programming software on the target. You can then choose between putting this code in a bootloader, putting it in the main application, or having it as a small stub that is only ever downloaded to ram as part of your programming sequence.

Here is a 5282 setup using vanilla Eclipse and CodeSourcery GCC. This instructions are just to run from RAM.

This one uses a 52233, but the instructions allow use from Flash.

--
Regards,
Richard.

NEW! FreeRTOS eBook:
http://www.freertos.org/Documentation/FreeRTOS-documentation-and-book.html

Responding to all. Thanks for all of the tips. I will look into these and plan on using BDM

(I have found some info on building the parallel port BDM interface) and have looked briefly at the toolchain options.

Looks like there is enough that I might actually be able to do this, on the cheap, homebrew.

If I actually go through with this (talking about it and actually doing it are two different things ), let the group know how it goes.

Now that it sounds dooable I will look more into the fabrication of the hardware.

Thanks ! Joe WB2JQT Newark Valley, NY