In article <85f19b17.0403180959.203796ef@posting.google.com>, 
hansch@cms.tecmath.de says...
> Tauno,
> 
> alright. I understand. 
> 
> So I need the following:
> 1. A programme on the MCU for reading a part of the
>    MCU's internal RAM and for copying it to the flash
>    RAM. 
> 2. A programme which loads parts of my final application
>    into the internal RAM.
> 3. A programme which is breaking up my s-records file (containing
>    my final application) into multiple parts which fit into
>    the internal RAM.
> 
> 1 is easy. 
> 2 I might use m*cgraigors OCD commander which works fine.
> 3 hmm. How schould I tell my linker to break it up into
>   different parts and how to re-allocate them (e.g. branch-
>   instructions) because they are loaded into a different
>   part of memory at the end...
> 
> Ideas?

My approach was to write my own host program (using Borland's C++ 
Builder)  which sends the S-Record file one line at a time.
The boot loader on the ARM reads the S-Record and puts the 
binary image in RAM, while saving the address part so it
knows the final destination.  The boot loader can decide
how many lines to load based on available RAM, then stop
as required and burn the RAM buffer to flash.  The PC host program waits 
for a confirmation character after each line, so it will
wait while the boot loader burns the flash segment.

I didn't have to worry about all the parts of this process, 
since I had as much RAM as Flash and the ARM could read,
decode and store in RAM as fast as the serial port could
send data at 115KB.  With the USB port, there is automatic
handshaking.  I guess the process would be more complicated
if the Flash image was not contiguous---you'd have to
note an address jump and start a new segment.   I guess it
would also be more complicated if the Flash required you
to burn complete blocks of a fixed size.



<<SNIP>>


Mark Borgerson

Daniel wrote:
> Tauno,
> 
> alright. I understand. 
> 
> So I need the following:
> 1. A programme on the MCU for reading a part of the
>    MCU's internal RAM and for copying it to the flash
>    RAM. 
> 2. A programme which loads parts of my final application
>    into the internal RAM.
> 3. A programme which is breaking up my s-records file (containing
>    my final application) into multiple parts which fit into
>    the internal RAM.
> 
> 1 is easy. 
> 2 I might use m*cgraigors OCD commander which works fine.
> 3 hmm. How schould I tell my linker to break it up into
>   different parts and how to re-allocate them (e.g. branch-
>   instructions) because they are loaded into a different
>   part of memory at the end...
> 
> Ideas?
> 

Right.

In my code, there are three fullwords at a fixed location
in the Flash writer module: the start address in RAM,
the start address in Flash, and the count. The values
are loaded together with the target code.

I have never used McRaigor's things - cannot help you there,
I'm using my own JTAG downloader.

Let the linker to make a full runfile and split it
afterwards. It's not too difficult to write small
utility programs able to read and write S-records.

If you're not too fussy about the split boundaries,
the S-record file can be split between the records
using any text editor - the file is all cleartext,
no binary there.

My download script is here:

-----------------

#!/bin/sh

# writeflash - Download code to ARM flash
# version 0.2, 3.5.2002, Tauno Voipio
# For AT91R40008
#
#  arg1: file name
#  arg2: offset in flash

# set up chip selects

./armtool write 0xffe00000 0x010022aa
./armtool write 0xffe00004 0x020022a9
./armtool write 0xffe00008 0x030024be
./armtool write 0xffe0000c 0x30000000
./armtool write 0xffe00010 0x40000000
./armtool write 0xffe00014 0x50000000
./armtool write 0xffe00018 0x60000000
./armtool write 0xffe0001c 0x70000000
./armtool write 0xffe00020 0x00000001
./armtool write 0xffe00024 0x00000006

# load flash writer

./armtool write 0x00038000 $(./filesize flashwr.axf) flashwr.axf

# load target

location=0x00002000
length=$(./filesize $1)

echo "Loading $1 to $location, $length bytes"

./armtool write $location $length $1

# set up flash writer

./armtool write 0x00038000 $2
./armtool write 0x00038008 $length

# write!

echo "Writing $length bytes to flash location $2"

./armtool xecute 0x0003800c

------------

It is a shell script for Linux. The JTAG tool is
here called ./armtool, and the commands should be
obvious.

The writes to locations 0x00038000 and 0x00038008 set
up the Flash writer parameters before doing the
write (at ./armtool xecute ..).

HTH

Tauno Voipio
tauno voipio @ iki fi

Tauno,

alright. I understand. 

So I need the following:
1. A programme on the MCU for reading a part of the
   MCU's internal RAM and for copying it to the flash
   RAM. 
2. A programme which loads parts of my final application
   into the internal RAM.
3. A programme which is breaking up my s-records file (containing
   my final application) into multiple parts which fit into
   the internal RAM.

1 is easy. 
2 I might use m*cgraigors OCD commander which works fine.
3 hmm. How schould I tell my linker to break it up into
  different parts and how to re-allocate them (e.g. branch-
  instructions) because they are loaded into a different
  part of memory at the end...

Ideas?

thanks & best regards,
Daniel



Tauno Voipio <tauno.voipio@iki.fi.NOSPAM.invalid> wrote in message news:<Ku06c.358$Ig5.109@read3.inet.fi>...
> Daniel wrote:
> > Dear all,
> > 
> > thanks for the replies.  
> > 
> > Conclusion:
> > 1. Method
> > 
> >>>> - a program able to write the Flash from the RAM
> >>>> - the program destined for the Flash
> >>>>
> >>>>After loading both pieces, I start the writer with
> >>>>the JTAG interface and let it do the programming.
> > 
> > 
> > This does not help for programmes which need more space than internally
> > available. My MCU has 16 KB internal RAM. This is not sufficient.
> 
> Transfer the code in slices. The Flash writer is less than
> 2 kbytes, so you should be able to have e.g. 12 kbytes slices.
> 
> The Flash programming algorithm is quite on the complicated
> side to be performed from JTAG directly.
> 
> To refresh the memory: the JTAG RAM write procedure:
> 
>   - load a LDMIA instruction into the pipeline
>   - load some NOP's to get to the execution cycle
>   - load the data for the LDMIA
>   - load a STMIA instruction in the pipeline
>   - execute the STMIA at full speed to access the memory
>   - stop the processor
>   - repeat loop till done
> 
> Add the Flash write sequence requirements to the above,
> so you'll see why it's not recommended (yes - it should
> be doable, never tried such a kludge).
> 
> Been there - done that.
> 
> Tauno Voipio
> tauno voipio @ iki fi

In article <40572EE0.8090306@-at-amontec.com>, laurent.gauch@-at-
amontec.com says...
> Mark Borgerson wrote:
> 
> > In article <ZID5c.181$K14.72@read3.inet.fi>, 
> > tauno.voipio@iki.fi.NOSPAM.invalid says...
> > 
> >>Daniel wrote:
> >>
> >>>Hi there!
> >>>
> >>>Does anybody has a software which I may use for programming my flash device
> >>>(AT29c040a) through the MCU's JTAG port?
> >>>
> >>>The MCU is LH75411 from Sharp which has a ARM7-TDMI core. I have a wiggler
> >>>and the macraigor's free OCD programmer in place. Both are working fine for
> >>>programming the internal RAM of the MCU.
> >>>
> >>>For programming the flash device, the OCD programmer is obviously not a
> >>>good choice since it is not taking care for the flash's timing restricitions
> >>>for programming. I actually tried to download my programme to the Flash
> >>>device, but only arbitrary "parts" of it have been stored.
> >>>
> >>>I know that macraigor offers a flash programming tool, but you need to
> >>>pay for the licence, which I am not willing to do...
> >>>
> >>>I appreciate any hint!
> >>>
> >>>Daniel
> >>
> >>I'm doing the corresponding load by loading two pieces of
> >>software into the processor RAM:
> >>
> >>  - a program able to write the Flash from the RAM
> >>  - the program destined for the Flash
> >>
> >>After loading both pieces, I start the writer with
> >>the JTAG interface and let it do the programming.
> >>
> >>My processor is AT91R40008 and the Flash is AM29DL163,
> >>but the same method should apply to all combinations.
> >>
> > 
> > 
> > ONe of my first projects for the ARM (AT91R40807, in my case)
> > was a simple monitor (about 2KBytes) that lives in RAM.  It
> > has the ability to burn itself to Flash and to load other
> > programs  from motorols S37 records that can then be
> > transferred to flash.  It was pretty straightforward in
> > my case, since the system had 128K of RAM in the Atmel
> > chip and 128K of flash.  I can load the final program
> > into RAM and burn it as a single large segment.
> > 
> > Later, I implemented a USB port with an FTDI '245
> > chip, and uploading an 88KByte program takes about 3 seconds.
> > The overall process of using a Wiggler to upload the 
> > monitor, burning the monitor, then uploading and burning
> > the code is pretty fast and simple enough for production
> > work with the final product.
> > 
> > 
> > BTW,  some early advice from Tauno was a key to my 
> > startup with the ARM.   I'm always amazed at how much
> > help you can get if you ask sensible questions in a
> > polite fashion on this newsgroup. 
> > 
> >>HTH
> >>
> >>Tauno Voipio
> >>tauno voipio @ iki fi
> >>
> >>
> > 
> > Mark Borgerson
> > 
> > 
> You can be 5x faster using Raven configuration of our Chameleon POD.
> Please look www.amontec.com,  we have high-speed and low-cost JTAG 
> device solutions.

Hmmm----5 times faster than uploading code through the USB port on
my board!  That would mean it would take 0.6 seconds to upload
code instead of 3.0 seconds.   I don't think it's worth $150 or
more to save myself  2.4 seconds on each load.  Might be worthwhile
to someone with a few megabytes of code, though.
> 
> We are working on an auto-baurate Raven configuration for all ARMx -S 
> device, using the RTCK as tck acknowledge !
> 
> Larry


Mark Borgerson

Mark Borgerson wrote:
> 
> BTW,  some early advice from Tauno was a key to my 
> startup with the ARM.   I'm always amazed at how much
> help you can get if you ask sensible questions in a
> polite fashion on this newsgroup. 
> 

Thank you, Mark! (blush!)

Tauno Voipio
tauno voipio @ iki fi

Daniel wrote:
> Dear all,
> 
> thanks for the replies.  
> 
> Conclusion:
> 1. Method
> 
>>>> - a program able to write the Flash from the RAM
>>>> - the program destined for the Flash
>>>>
>>>>After loading both pieces, I start the writer with
>>>>the JTAG interface and let it do the programming.
> 
> 
> This does not help for programmes which need more space than internally
> available. My MCU has 16 KB internal RAM. This is not sufficient.

Transfer the code in slices. The Flash writer is less than
2 kbytes, so you should be able to have e.g. 12 kbytes slices.

The Flash programming algorithm is quite on the complicated
side to be performed from JTAG directly.

To refresh the memory: the JTAG RAM write procedure:

  - load a LDMIA instruction into the pipeline
  - load some NOP's to get to the execution cycle
  - load the data for the LDMIA
  - load a STMIA instruction in the pipeline
  - execute the STMIA at full speed to access the memory
  - stop the processor
  - repeat loop till done

Add the Flash write sequence requirements to the above,
so you'll see why it's not recommended (yes - it should
be doable, never tried such a kludge).

Been there - done that.

Tauno Voipio
tauno voipio @ iki fi

Dear all,

thanks for the replies.  

Conclusion:
1. Method
> >>
> >>  - a program able to write the Flash from the RAM
> >>  - the program destined for the Flash
> >>
> >>After loading both pieces, I start the writer with
> >>the JTAG interface and let it do the programming.

This does not help for programmes which need more space than internally
available. My MCU has 16 KB internal RAM. This is not sufficient.

2. Method:
> > 
> > ONe of my first projects for the ARM (AT91R40807, in my case)
> > was a simple monitor (about 2KBytes) that lives in RAM.  It
> > has the ability to burn itself to Flash and to load other
> > programs  from motorols S37 records that can then be
> > transferred to flash.  It was pretty straightforward in
> > my case, since the system had 128K of RAM in the Atmel
> > chip and 128K of flash.  I can load the final program
> > into RAM and burn it as a single large segment.

Any ideas how to programmatically control the jtag port for writing
the srecords file to MCU from PC and for reading the file from jtag
port by the MCU?

I think, this is the key.

Ideas? Code snippets?

thanks,
Daniel

Mark Borgerson wrote:

> In article <ZID5c.181$K14.72@read3.inet.fi>, 
> tauno.voipio@iki.fi.NOSPAM.invalid says...
> 
>>Daniel wrote:
>>
>>>Hi there!
>>>
>>>Does anybody has a software which I may use for programming my flash device
>>>(AT29c040a) through the MCU's JTAG port?
>>>
>>>The MCU is LH75411 from Sharp which has a ARM7-TDMI core. I have a wiggler
>>>and the macraigor's free OCD programmer in place. Both are working fine for
>>>programming the internal RAM of the MCU.
>>>
>>>For programming the flash device, the OCD programmer is obviously not a
>>>good choice since it is not taking care for the flash's timing restricitions
>>>for programming. I actually tried to download my programme to the Flash
>>>device, but only arbitrary "parts" of it have been stored.
>>>
>>>I know that macraigor offers a flash programming tool, but you need to
>>>pay for the licence, which I am not willing to do...
>>>
>>>I appreciate any hint!
>>>
>>>Daniel
>>
>>I'm doing the corresponding load by loading two pieces of
>>software into the processor RAM:
>>
>>  - a program able to write the Flash from the RAM
>>  - the program destined for the Flash
>>
>>After loading both pieces, I start the writer with
>>the JTAG interface and let it do the programming.
>>
>>My processor is AT91R40008 and the Flash is AM29DL163,
>>but the same method should apply to all combinations.
>>
> 
> 
> ONe of my first projects for the ARM (AT91R40807, in my case)
> was a simple monitor (about 2KBytes) that lives in RAM.  It
> has the ability to burn itself to Flash and to load other
> programs  from motorols S37 records that can then be
> transferred to flash.  It was pretty straightforward in
> my case, since the system had 128K of RAM in the Atmel
> chip and 128K of flash.  I can load the final program
> into RAM and burn it as a single large segment.
> 
> Later, I implemented a USB port with an FTDI '245
> chip, and uploading an 88KByte program takes about 3 seconds.
> The overall process of using a Wiggler to upload the 
> monitor, burning the monitor, then uploading and burning
> the code is pretty fast and simple enough for production
> work with the final product.
> 
> 
> BTW,  some early advice from Tauno was a key to my 
> startup with the ARM.   I'm always amazed at how much
> help you can get if you ask sensible questions in a
> polite fashion on this newsgroup. 
> 
>>HTH
>>
>>Tauno Voipio
>>tauno voipio @ iki fi
>>
>>
> 
> Mark Borgerson
> 
> 
You can be 5x faster using Raven configuration of our Chameleon POD.
Please look www.amontec.com,  we have high-speed and low-cost JTAG 
device solutions.

We are working on an auto-baurate Raven configuration for all ARMx -S 
device, using the RTCK as tck acknowledge !

Larry

In article <ZID5c.181$K14.72@read3.inet.fi>, 
tauno.voipio@iki.fi.NOSPAM.invalid says...
> Daniel wrote:
> > Hi there!
> > 
> > Does anybody has a software which I may use for programming my flash device
> > (AT29c040a) through the MCU's JTAG port?
> > 
> > The MCU is LH75411 from Sharp which has a ARM7-TDMI core. I have a wiggler
> > and the macraigor's free OCD programmer in place. Both are working fine for
> > programming the internal RAM of the MCU.
> > 
> > For programming the flash device, the OCD programmer is obviously not a
> > good choice since it is not taking care for the flash's timing restricitions
> > for programming. I actually tried to download my programme to the Flash
> > device, but only arbitrary "parts" of it have been stored.
> > 
> > I know that macraigor offers a flash programming tool, but you need to
> > pay for the licence, which I am not willing to do...
> > 
> > I appreciate any hint!
> > 
> > Daniel
> 
> I'm doing the corresponding load by loading two pieces of
> software into the processor RAM:
> 
>   - a program able to write the Flash from the RAM
>   - the program destined for the Flash
> 
> After loading both pieces, I start the writer with
> the JTAG interface and let it do the programming.
> 
> My processor is AT91R40008 and the Flash is AM29DL163,
> but the same method should apply to all combinations.
>

ONe of my first projects for the ARM (AT91R40807, in my case)
was a simple monitor (about 2KBytes) that lives in RAM.  It
has the ability to burn itself to Flash and to load other
programs  from motorols S37 records that can then be
transferred to flash.  It was pretty straightforward in
my case, since the system had 128K of RAM in the Atmel
chip and 128K of flash.  I can load the final program
into RAM and burn it as a single large segment.

Later, I implemented a USB port with an FTDI '245
chip, and uploading an 88KByte program takes about 3 seconds.
The overall process of using a Wiggler to upload the 
monitor, burning the monitor, then uploading and burning
the code is pretty fast and simple enough for production
work with the final product.


BTW,  some early advice from Tauno was a key to my 
startup with the ARM.   I'm always amazed at how much
help you can get if you ask sensible questions in a
polite fashion on this newsgroup. 
> HTH
> 
> Tauno Voipio
> tauno voipio @ iki fi
> 
> 
Mark Borgerson

Daniel wrote:
> Hi there!
> 
> Does anybody has a software which I may use for programming my flash device
> (AT29c040a) through the MCU's JTAG port?
> 
> The MCU is LH75411 from Sharp which has a ARM7-TDMI core. I have a wiggler
> and the macraigor's free OCD programmer in place. Both are working fine for
> programming the internal RAM of the MCU.
> 
> For programming the flash device, the OCD programmer is obviously not a
> good choice since it is not taking care for the flash's timing restricitions
> for programming. I actually tried to download my programme to the Flash
> device, but only arbitrary "parts" of it have been stored.
> 
> I know that macraigor offers a flash programming tool, but you need to
> pay for the licence, which I am not willing to do...
> 
> I appreciate any hint!
> 
> Daniel

I'm doing the corresponding load by loading two pieces of
software into the processor RAM:

  - a program able to write the Flash from the RAM
  - the program destined for the Flash

After loading both pieces, I start the writer with
the JTAG interface and let it do the programming.

My processor is AT91R40008 and the Flash is AM29DL163,
but the same method should apply to all combinations.

HTH

Tauno Voipio
tauno voipio @ iki fi