Didi wrote:
> David Brown wrote:
>> (for example, you can download a memory test
>> routine to internal ram and run that much faster than a boundary scan
>> based memory test),
> 
> You can download the memory test using the right JTAG tools as well.
> 
>> and probably vastly cheaper and easier to set up.
> 
> It will take some figures to make me believe that... :-)
> 

Another poster gave you the prices for a Cybertec BDM unit (I've got one 
- it works well) along with the open source BDM software.  That's a very 
flexible solution, although it might take some time to get set up as you 
want it if you are not used to that sort of software.  For a 
ready-to-run and easy-to-use solution, you can look at P&E Micro, which 
includes software, but costs a little more.

The JTAG boundary scan hardware and software we heard about was very 
much more expensive - a completely different price class.  I'm sure that 
when used appropriately, such tools can be very worthwhile, but they are 
for a different job.

Many micros have a JTAG with "secret" registers (which may or may not be 
documented) for debugging and programming - I'd classify these along 
with Freescale's BDM interface.  You typically buy/build a dedicated 
dongle, consisting of a parallel port connector and a couple of logic 
chips and resistors, and use cheap or free software for programming.

But using general purpose boundary scan for programming flash when you 
have a micro on board ready to do the work, seems a poor solution to me, 
akin to using an embedded PC for an embedded system when a small 
8-bitter would do the job.

>> I'd be very surprised if boundary scan techniques were the best solution for flash
>> programming for most users - although I don't know much about its use in
>> practice other than what some sales reps told me.
> 
> I'd be less than surprised if they were, actually - provided the tools
> those
> sales reps told you about were capable of doing it (many are not).
> They typically use the secret JTAG registers which - surprise - are
> documented
> only for tool vendors owned by or closely related to the manufacturer.
> Why are they doing it is another matter (the profits JTAG toolvendors
> make
> are negligible for big silicon manufacturers).
> Using general JTAG capabilities only has its advantages .
> I must admit, though, that with the growing complexity and all those
> mergers/acquisitions staying independent becomes more difficult every
> day...
> 
> Dimiter
> 
> ------------------------------------------------------
> Dimiter Popoff               Transgalactic Instruments
> 
> http://www.tgi-sci.com
> ------------------------------------------------------
> 

Didi wrote:
> David Brown wrote:
>> (for example, you can download a memory test
>> routine to internal ram and run that much faster than a boundary scan
>> based memory test),
> 
> You can download the memory test using the right JTAG tools as well.
> 
>> and probably vastly cheaper and easier to set up.
> 
> It will take some figures to make me believe that... :-)


www.cybertec.com.au: BDM Pod, $99 US
Software:

http://sourceforge.net/projects/bdm

Free. (as in Beer and Speech).

Compiles for linux and windows.

On a recent project I used the library to write
a custom flash programmer / production tester.

Regards


Paul

David Brown wrote:
> (for example, you can download a memory test
> routine to internal ram and run that much faster than a boundary scan
> based memory test),

You can download the memory test using the right JTAG tools as well.

> and probably vastly cheaper and easier to set up.

It will take some figures to make me believe that... :-)

> I'd be very surprised if boundary scan techniques were the best solution for flash
> programming for most users - although I don't know much about its use in
> practice other than what some sales reps told me.

I'd be less than surprised if they were, actually - provided the tools
those
sales reps told you about were capable of doing it (many are not).
They typically use the secret JTAG registers which - surprise - are
documented
only for tool vendors owned by or closely related to the manufacturer.
Why are they doing it is another matter (the profits JTAG toolvendors
make
are negligible for big silicon manufacturers).
Using general JTAG capabilities only has its advantages .
I must admit, though, that with the growing complexity and all those
mergers/acquisitions staying independent becomes more difficult every
day...

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

Didi wrote:
> David Brown wrote:
> 
>> Some Coldfires have JTAG interfaces, but (on the Coldfires I have used)
>> this is only for boundary scan.  The BDM port is for debugging and can
>> easily be used for programming.  There are lots of tools on the market,
>> ranging from free (cheap or home-made bdm dongle, combined with
>> open-source software) to very capable but expensive tools (such as
>> Abatron).  You probably want to have a look at www.pemicro.com for
>> reasonably priced tools, including flash programming software.
>>
> 
> I meant exactly using the boundary scan to program the flash,
> this is how I am doing it with my tools. BDM or secret JTAG
> registers based tools may work, but are a lot less universal
> and get you stuck with the suplier as you don't know what they
> are doing (I am not sure about BDM, actually, it used to be
> documented up to a point for CPU32, but it is a unique interface
> anyway whereas JTAG is pretty widespread).
>  I did not know the Coldfire had BDM, years ago, when I was looking
> where to move to from CPU32, I opted for the PPC and have not
> looked at the Coldfire since.
> 
> Dimiter
> 

The Coldfire BDM, like the CPU32 BDM, is pretty well documented.  It is 
a noticeable improvement over the CPU32 BDM (less pin multiplexing, and 
some more internal hardware).  Like "secret JTAG register tools", using 
the BDM rather than generic boundary scan flash programming is going to 
be very much more efficient (whether that is relevant or not depends on 
your flash programming speed, and the size of the download), more 
flexible for some uses (for example, you can download a memory test 
routine to internal ram and run that much faster than a boundary scan 
based memory test), and probably vastly cheaper and easier to set up. 
If you already use boundary scan extensively, and have the required 
software, then it's a different matter, obviously.  I'd be very 
surprised if boundary scan techniques were the best solution for flash 
programming for most users - although I don't know much about its use in 
practice other than what some sales reps told me.

David Brown wrote:

> Some Coldfires have JTAG interfaces, but (on the Coldfires I have used)
> this is only for boundary scan.  The BDM port is for debugging and can
> easily be used for programming.  There are lots of tools on the market,
> ranging from free (cheap or home-made bdm dongle, combined with
> open-source software) to very capable but expensive tools (such as
> Abatron).  You probably want to have a look at www.pemicro.com for
> reasonably priced tools, including flash programming software.
>

I meant exactly using the boundary scan to program the flash,
this is how I am doing it with my tools. BDM or secret JTAG
registers based tools may work, but are a lot less universal
and get you stuck with the suplier as you don't know what they
are doing (I am not sure about BDM, actually, it used to be
documented up to a point for CPU32, but it is a unique interface
anyway whereas JTAG is pretty widespread).
 I did not know the Coldfire had BDM, years ago, when I was looking
where to move to from CPU32, I opted for the PPC and have not
looked at the Coldfire since.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

Didi wrote:
>> Sorry, if this question is stupid. I have only experience with PIC
>> microcontrollers, where this is possible.
>>
>> Jens
>>
> 
> Jens,
> with bigger CPUs your only bet is JTAG - I believe the Coldfire has it.
> With CPU32, they also have the BDM interface, which also can be
> used.

Some Coldfires have JTAG interfaces, but (on the Coldfires I have used) 
this is only for boundary scan.  The BDM port is for debugging and can 
easily be used for programming.  There are lots of tools on the market, 
ranging from free (cheap or home-made bdm dongle, combined with 
open-source software) to very capable but expensive tools (such as 
Abatron).  You probably want to have a look at www.pemicro.com for 
reasonably priced tools, including flash programming software.

> I have always used JTAG (even on CPU32), because it also takes
> care of debugging the board, programming the CPLDs etc.
>  In order to just solder the flash memory to the board and program
> it for the first time, you drive the address and data lines via JTAG
> so the flash gets programmed. Takes longer because of the serial
> nature of JTAG, but you really need to write some loader which could
> subsequently program the whole flash via a faster interface. Anyway,
> apparently you ask only about that first ever programming, you know
> what to do afterwards.
>  I am not aware of the PC based tools as I use my own, DPS based
> hard/software, so perhaps someone else could suggest what you
> need to be able to do that.
> 
> Dimiter
> 
> ------------------------------------------------------
> Dimiter Popoff               Transgalactic Instruments
> 
> http://www.tgi-sci.com
> ------------------------------------------------------
> 

Didi wrote:

> with bigger CPUs your only bet is JTAG - I believe the Coldfire has it.

I think, this answers my question. Didn't know that JTAG is the solution. I
will need to get familiar with this interface. Thank you!

Jens

> Sorry, if this question is stupid. I have only experience with PIC
> microcontrollers, where this is possible.
>
> Jens
>

Jens,
with bigger CPUs your only bet is JTAG - I believe the Coldfire has it.
With CPU32, they also have the BDM interface, which also can be
used.
I have always used JTAG (even on CPU32), because it also takes
care of debugging the board, programming the CPLDs etc.
 In order to just solder the flash memory to the board and program
it for the first time, you drive the address and data lines via JTAG
so the flash gets programmed. Takes longer because of the serial
nature of JTAG, but you really need to write some loader which could
subsequently program the whole flash via a faster interface. Anyway,
apparently you ask only about that first ever programming, you know
what to do afterwards.
 I am not aware of the PC based tools as I use my own, DPS based
hard/software, so perhaps someone else could suggest what you
need to be able to do that.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

Peter wrote:

> You'll have to write your own bootloader and put it in ROM. You need to
> implement a filing system to get the boot code off a flash memory card and
> copy it to RAM, then execute the code in RAM.

Thanks, Peter. I'm aware, that I have to copy the operating system's code
from Flash to RAM. However, I want to avoid adding an extra boot ROM.
(Besides, is it possible to program Flash RAM before soldering it into the
circuit board? Or are the data likely to be destroyed during soldering?)
If the Coldfire doesn't support a mode to reprogram Flash, are there any
devices, that allow this procedure? I imagine to change some jumpers,
program Flash via a serial interface (USB,RS232,I2C), set jumpers back to
normal operation.
Sorry, if this question is stupid. I have only experience with PIC
microcontrollers, where this is possible.

Jens

> To cope with the first time 
> when you start with a blank card without any boot code it needs to be able
> to accept an initial upload from the serial port.
> 
> New versions of software can be uploaded by serial port. Just write some
> code that accepts whatever format your linker puts out. Copy this to RAM
> and when the transfer is complete then write the boot code to flash.
> Peter

"Herbert Wagner" <hw.privat@web.de> wrote in message 
news:43ccc9aa$0$15795$14726298@news.sunsite.dk...
> Hi!
> Does anyone know, if the Coldfire (Manual at
> http://www.freescale.com/files/netcomm/doc/ref_manual/MCF5206SECUM.html)
> supports a bootstrap mode similar to the one described in section 16 of 
> the
> Dragonball manual 
> (http://www.openhardware.net/pdf_files/MC68EZ328UM1.pdf)?
>
> If not, what is the simplest solution (from the hardware point of view) to
> allow the Flash RAM of an SBC to be reprogrammed (in circuit) via a serial
> or USB interface? I'd appreciate some reference schematics or maybe a
> simplified sketch.
>
> Thanks,
> Jens

----- Original Message ----- 
From: "Herbert Wagner" <hw.privat@web.de>
Newsgroups: comp.arch.embedded
Sent: Tuesday, January 17, 2006 10:40 AM
Subject: bootstrap mode for Motorola Coldfire MCF5206?


> Hi!
> Does anyone know, if the Coldfire (Manual at
> http://www.freescale.com/files/netcomm/doc/ref_manual/MCF5206SECUM.html)
> supports a bootstrap mode similar to the one described in section 16 of 
> the
> Dragonball manual 
> (http://www.openhardware.net/pdf_files/MC68EZ328UM1.pdf)?
>
> If not, what is the simplest solution (from the hardware point of view) to
> allow the Flash RAM of an SBC to be reprogrammed (in circuit) via a serial
> or USB interface? I'd appreciate some reference schematics or maybe a
> simplified sketch.
>
> Thanks,
> Jens

You'll have to write your own bootloader and put it in ROM. You need to 
implement a filing system to get the boot code off a flash memory card and 
copy it to RAM, then execute the code in RAM. To cope with the first time 
when you start with a blank card without any boot code it needs to be able 
to accept an initial upload from the serial port.

New versions of software can be uploaded by serial port. Just write some 
code that accepts whatever format your linker puts out. Copy this to RAM and 
when the transfer is complete then write the boot code to flash.
Peter