DSPRelated.com
Forums

how to load .out file from a running program

Started by lime...@freenet.de May 7, 2007
hi,

i use dsk6711 with network daughtercard and the network example Filexfer from ndk/examples,
i want that the running filexfer example loads a new .out file and stores it to the sdram. And finally jump to the new .out file and run it.

1.do i have to load a .out-file or a .hex-file?
2.how can i store it to a place in sdram?
3.how can the dsp jump to the new .out-file and run it?

thank
Murat C.
Limes,

I have done this sort of thing.

I found that the linker info in the .out file makes it a very poor choice for loading.

The best file format I have found is a .bin file, that is an image of what you want in memory.
You need to know the entry offset in the file being loaded and the load address.
Then it is a simple jump to the (load address + offset).

R. Williams
---------- Original Message -----------
From: l...@freenet.de
To: c...
Sent: Mon, 07 May 2007 10:01:40 -0400
Subject: [c6x] how to load .out file from a running program

> hi,
>
> i use dsk6711 with network daughtercard and the network example Filexfer from ndk/examples,
> i want that the running filexfer example loads a new .out file and stores it to the
> sdram. And finally jump to the new .out file and run it.
>
> 1.do i have to load a .out-file or a .hex-file?
> 2.how can i store it to a place in sdram?
> 3.how can the dsp jump to the new .out-file and run it?
>
> thank
> Murat C.
------- End of Original Message -------
I have been interested in this sort of thing for a simple maintenence
program for a long time. I like your suggestion, and it leaves me with
a couple of questions.

How do you create a .bin file?

Is your .bin file relocatable after it's been created? Can you load the
file at an arbitrary location, and pass control to the correct offset,
and the program will do the standard C/C++ initialization and run main()?

Wim.

Richard Williams wrote:
> I found that the linker info in the .out file makes it a very poor choice for loading.
>
> The best file format I have found is a .bin file, that is an image of what you want in memory.
> You need to know the entry offset in the file being loaded and the load address.
> Then it is a simple jump to the (load address + offset).
>
> ---------- Original Message -----------
> From: l...@freenet.de
> To: c...
> Sent: Mon, 07 May 2007 10:01:40 -0400
> Subject: [c6x] how to load .out file from a running program
>
>
>> hi,
>>
>> i use dsk6711 with network daughtercard and the network example Filexfer from ndk/examples,
>> i want that the running filexfer example loads a new .out file and stores it to the
>> sdram. And finally jump to the new .out file and run it.
>>
>> 1.do i have to load a .out-file or a .hex-file?
>> 2.how can i store it to a place in sdram?
>> 3.how can the dsp jump to the new .out-file and run it?
>>
wbonner,

Did you see my prior email about the steps to create the .bin file?

The .bin file is a absolute image for a specific address in memory.
So loading it to an arbitrary location is not likely.

However a real help is to have the first file loaded contain a list
of all the other files to be loaded with their load address and execution offset address for each file.
the .hex file produced by the hex2000.exe utility (the specific name may be different for each
processor) contains some address information for each section of the original .out file (I.E. the
.text section, the .const section, etc.)

Those hex2bin.exe files found on the internet are for big Endian, 8bit byte files so will not work
for the TMS320 series of DSPs.
SO you will have to write your own utilities (to run on the PC) to do the conversion from .hex to
one or more .bin files.

the parameters for the HEX2000.exe utility are very vague, so call TI to get the specific parameters
to produce a single output .hex file for your processor.

R. Williams
---------- Original Message -----------
From: William C Bonner
To: Richard Williams
Cc: l...@freenet.de, c...
Sent: Tue, 08 May 2007 07:22:55 -0700
Subject: Re: [c6x] how to load .out file from a running program

> I have been interested in this sort of thing for a simple maintenence
> program for a long time. I like your suggestion, and it leaves me with
> a couple of questions.
>
> How do you create a .bin file?
>
> Is your .bin file relocatable after it's been created? Can you load the
> file at an arbitrary location, and pass control to the correct offset,
> and the program will do the standard C/C++ initialization and run main()?
>
> Wim.
>
> Richard Williams wrote:
> > I found that the linker info in the .out file makes it a very poor choice for loading.
> >
> > The best file format I have found is a .bin file, that is an image of what you want in memory.
> > You need to know the entry offset in the file being loaded and the load address.
> > Then it is a simple jump to the (load address + offset).
> >
> > ---------- Original Message -----------
> > From: l...@freenet.de
> > To: c...
> > Sent: Mon, 07 May 2007 10:01:40 -0400
> > Subject: [c6x] how to load .out file from a running program
> >
> >
> >> hi,
> >>
> >> i use dsk6711 with network daughtercard and the network example Filexfer from ndk/examples,
> >> i want that the running filexfer example loads a new .out file and stores it to the
> >> sdram. And finally jump to the new .out file and run it.
> >>
> >> 1.do i have to load a .out-file or a .hex-file?
> >> 2.how can i store it to a place in sdram?
> >> 3.how can the dsp jump to the new .out-file and run it?
> >>
------- End of Original Message -------
I don't think I saw your steps for creating a .bin file, or I didn't
understand them completely if I saw them.

I am using a custom board with a bios from http://dsignt.de/ that has a
bootload() command that will load a program from flash and pass control
in a stable way. I have written programs on the PC that change the HEX
file into a binary file, that I use the extension .bin for. I have
found that the binary codes in the HEX file are the same if I tell the
HEX creator (coff out in hex out) different load locations, only the
address on each line in the hex file is different. this allows me to
efficiently locate things in flash.

There are two reasons that I'm using the binary file instead of the hex
file to load the flash. I'm doing this over a serial connection and a
hex file has a checksum per line, but no global checksum, and so I felt
i needed to have a more secure file transfer protocol to verify a
complete transfer before i write the new platform code to flash. I'm
using Z Modem, but I could be using X or Y Modem. I'm doing this over a
serial connection and going from hex to binary drops the file size to be
transferred in half, producing a faster transfer.

At various times I've wanted to be able to transfer a code image to ram,
instead of flash, and then transfer control to it. The gymnastics
involved with wanting to be able to use the ram for both the original
program and the newly received program probably preclude this ever
working. I suppose there might be some way of running code directly
from flash, if I were to tell the cache processor to cache the flash and
only use a specific part of ram for data. Like I said, gymnastics that
are probably too constraining for long term support.

I have changed from using a single monolithic project that does
everything from platform maintenance to decoding to having several
different programs that get switched between using the boatload function
I mentioned above. The different programs use the cache controller in
different modes, but they all use ~100% of the internal DSP ram and
varying amounts of my external SRAM.

Richard Williams wrote:
> Did you see my prior email about the steps to create the .bin file?
>
> The .bin file is a absolute image for a specific address in memory.
> So loading it to an arbitrary location is not likely.
>
> However a real help is to have the first file loaded contain a list
> of all the other files to be loaded with their load address and execution offset address for each file.
> the .hex file produced by the hex2000.exe utility (the specific name may be different for each
> processor) contains some address information for each section of the original .out file (I.E. the
> .text section, the .const section, etc.)
>
> Those hex2bin.exe files found on the internet are for big Endian, 8bit byte files so will not work
> for the TMS320 series of DSPs.
> SO you will have to write your own utilities (to run on the PC) to do the conversion from .hex to
> one or more .bin files.
>
> the parameters for the HEX2000.exe utility are very vague, so call TI to get the specific parameters
> to produce a single output .hex file for your processor.
>
> R. Williams
> ---------- Original Message -----------
> From: William C Bonner
> To: Richard Williams
> Cc: l...@freenet.de, c...
> Sent: Tue, 08 May 2007 07:22:55 -0700
> Subject: Re: [c6x] how to load .out file from a running program
>
>
>> I have been interested in this sort of thing for a simple maintenence
>> program for a long time. I like your suggestion, and it leaves me with
>> a couple of questions.
>>
>> How do you create a .bin file?
>>
>> Is your .bin file relocatable after it's been created? Can you load the
>> file at an arbitrary location, and pass control to the correct offset,
>> and the program will do the standard C/C++ initialization and run main()?
>>
>> Wim.
>>
>> Richard Williams wrote:
>>
>>> I found that the linker info in the .out file makes it a very poor choice for loading.
>>>
>>> The best file format I have found is a .bin file, that is an image of what you want in memory.
>>> You need to know the entry offset in the file being loaded and the load address.
>>> Then it is a simple jump to the (load address + offset).
>>>
>>> ---------- Original Message -----------
>>> From: l...@freenet.de
>>> To: c...
>>> Sent: Mon, 07 May 2007 10:01:40 -0400
>>> Subject: [c6x] how to load .out file from a running program
>>>
>>>
>>>
>>>> hi,
>>>>
>>>> i use dsk6711 with network daughtercard and the network example Filexfer from ndk/examples,
>>>> i want that the running filexfer example loads a new .out file and stores it to the
>>>> sdram. And finally jump to the new .out file and run it.
>>>>
>>>> 1.do i have to load a .out-file or a .hex-file?
>>>> 2.how can i store it to a place in sdram?
>>>> 3.how can the dsp jump to the new .out-file and run it?
>>>>
>>>>
hi,
i need a way to load an .out-file over the network,
i have a networkprogram which runs on the dsp6711
know i can send any file via tcp-stream from pc to dsp
but i don`t know how to put this .out-file in sdram
that the dsp knows there is a new .out-file, so it can run it

so my aim is to load a program over the network from a running program on the dsp

nice day

I don't think I saw your steps for creating a .bin file, or I didn't
>understand them completely if I saw them.
>
>I am using a custom board with a bios from http://dsignt.de/ that has a
>bootload() command that will load a program from flash and pass control
>in a stable way. I have written programs on the PC that change the HEX
>file into a binary file, that I use the extension .bin for. I have
>found that the binary codes in the HEX file are the same if I tell the
>HEX creator (coff out in hex out) different load locations, only the
>address on each line in the hex file is different. this allows me to
>efficiently locate things in flash.
>
>There are two reasons that I'm using the binary file instead of the hex
>file to load the flash. I'm doing this over a serial connection and a
>hex file has a checksum per line, but no global checksum, and so I felt
>i needed to have a more secure file transfer protocol to verify a
>complete transfer before i write the new platform code to flash. I'm
>using Z Modem, but I could be using X or Y Modem. I'm doing this over a
>serial connection and going from hex to binary drops the file size to be
>transferred in half, producing a faster transfer.
>
>At various times I've wanted to be able to transfer a code image to ram,
>instead of flash, and then transfer control to it. The gymnastics
>involved with wanting to be able to use the ram for both the original
>program and the newly received program probably preclude this ever
>working. I suppose there might be some way of running code directly
>from flash, if I were to tell the cache processor to cache the flash and
>only use a specific part of ram for data. Like I said, gymnastics that
>are probably too constraining for long term support.
>
>I have changed from using a single monolithic project that does
>everything from platform maintenance to decoding to having several
>different programs that get switched between using the boatload function
>I mentioned above. The different programs use the cache controller in
>different modes, but they all use ~100% of the internal DSP ram and
>varying amounts of my external SRAM.
>
>Richard Williams wrote:
>> Did you see my prior email about the steps to create the .bin file?
>>
>> The .bin file is a absolute image for a specific address in memory.
>> So loading it to an arbitrary location is not likely.
>>
>> However a real help is to have the first file loaded contain a list
>> of all the other files to be loaded with their load address and execution offset address for each file.
>> the .hex file produced by the hex2000.exe utility (the specific name may be different for each
>> processor) contains some address information for each section of the original .out file (I.E. the
>> .text section, the .const section, etc.)
>>
>> Those hex2bin.exe files found on the internet are for big Endian, 8bit byte files so will not work
>> for the TMS320 series of DSPs.
>> SO you will have to write your own utilities (to run on the PC) to do the conversion from .hex to
>> one or more .bin files.
>>
>> the parameters for the HEX2000.exe utility are very vague, so call TI to get the specific parameters
>> to produce a single output .hex file for your processor.
>>
>> R. Williams
>> ---------- Original Message -----------
>> From: William C Bonner
>> To: Richard Williams
>> Cc: l...@freenet.de, c...
>> Sent: Tue, 08 May 2007 07:22:55 -0700
>> Subject: Re: [c6x] how to load .out file from a running program
>>
>>
>> > I have been interested in this sort of thing for a simple maintenence
>> > program for a long time. I like your suggestion, and it leaves me with
>> > a couple of questions.
>> >
>> > How do you create a .bin file?
>> >
>> > Is your .bin file relocatable after it's been created? Can you load the
>> > file at an arbitrary location, and pass control to the correct offset,
>> > and the program will do the standard C/C++ initialization and run main()?
>> >
>> > Wim.
>> >
>> > Richard Williams wrote:
>> >
>> > > I found that the linker info in the .out file makes it a very poor choice for loading.
>> > >
>> > > The best file format I have found is a .bin file, that is an image of what you want in memory.
>> > > You need to know the entry offset in the file being loaded and the load address.
>> > > Then it is a simple jump to the (load address + offset).
>> > >
>> > > ---------- Original Message -----------
>> > > From: l...@freenet.de
>> > > To: c...
>> > > Sent: Mon, 07 May 2007 10:01:40 -0400
>> > > Subject: [c6x] how to load .out file from a running program
>> > >
>> > >
>> > >
>> > > > hi,
>> > > >
>> > > > i use dsk6711 with network daughtercard and the network example Filexfer from ndk/examples,
>> > > > i want that the running filexfer example loads a new .out file and stores it to the
>> > > > sdram. And finally jump to the new .out file and run it.
>> > > >
>> > > > 1.do i have to load a .out-file or a .hex-file?
>> > > > 2.how can i store it to a place in sdram?
>> > > > 3.how can the dsp jump to the new .out-file and run it?
>> > > >
>> > > >
Limes-

> i need a way to load an .out-file over the network,
> i have a networkprogram which runs on the dsp6711
> know i can send any file via tcp-stream from pc to dsp
> but i don`t know how to put this .out-file in sdram
> that the dsp knows there is a new .out-file, so it can run it
>
> so my aim is to load a program over the network from a running program on the dsp

You should transfer a .hex file, not a .out file. The .out file contains symbol
table and other information for debug purposes. Check out the the hex6x.exe utility
program.

The basic problem you're going to have is that the DSP is already running. After you
transfer the hex file and store into SDRAM, then you need to:

-transfer control to a small loop running "away" from
everything else. Anything the previous program was
doing must be terminated (no DMA, no I/O, all
interrupts disabled, etc)

-parse the hex data and transfer it to appropriate
places in memory... make sure not to "step on" the
small control loop code

-transfer control to the Reset vector

-Jeff

> I don't think I saw your steps for creating a .bin file, or I didn't
> >understand them completely if I saw them.
> >
> >I am using a custom board with a bios from http://dsignt.de/ that has a
> >bootload() command that will load a program from flash and pass control
> >in a stable way. I have written programs on the PC that change the HEX
> >file into a binary file, that I use the extension .bin for. I have
> >found that the binary codes in the HEX file are the same if I tell the
> >HEX creator (coff out in hex out) different load locations, only the
> >address on each line in the hex file is different. this allows me to
> >efficiently locate things in flash.
> >
> >There are two reasons that I'm using the binary file instead of the hex
> >file to load the flash. I'm doing this over a serial connection and a
> >hex file has a checksum per line, but no global checksum, and so I felt
> >i needed to have a more secure file transfer protocol to verify a
> >complete transfer before i write the new platform code to flash. I'm
> >using Z Modem, but I could be using X or Y Modem. I'm doing this over a
> >serial connection and going from hex to binary drops the file size to be
> >transferred in half, producing a faster transfer.
> >
> >At various times I've wanted to be able to transfer a code image to ram,
> >instead of flash, and then transfer control to it. The gymnastics
> >involved with wanting to be able to use the ram for both the original
> >program and the newly received program probably preclude this ever
> >working. I suppose there might be some way of running code directly
> >from flash, if I were to tell the cache processor to cache the flash and
> >only use a specific part of ram for data. Like I said, gymnastics that
> >are probably too constraining for long term support.
> >
> >I have changed from using a single monolithic project that does
> >everything from platform maintenance to decoding to having several
> >different programs that get switched between using the boatload function
> >I mentioned above. The different programs use the cache controller in
> >different modes, but they all use ~100% of the internal DSP ram and
> >varying amounts of my external SRAM.
> >
> >Richard Williams wrote:
> >> Did you see my prior email about the steps to create the .bin file?
> >>
> >> The .bin file is a absolute image for a specific address in memory.
> >> So loading it to an arbitrary location is not likely.
> >>
> >> However a real help is to have the first file loaded contain a list
> >> of all the other files to be loaded with their load address and execution offset address for each file.
> >> the .hex file produced by the hex2000.exe utility (the specific name may be different for each
> >> processor) contains some address information for each section of the original .out file (I.E. the
> >> .text section, the .const section, etc.)
> >>
> >> Those hex2bin.exe files found on the internet are for big Endian, 8bit byte files so will not work
> >> for the TMS320 series of DSPs.
> >> SO you will have to write your own utilities (to run on the PC) to do the conversion from .hex to
> >> one or more .bin files.
> >>
> >> the parameters for the HEX2000.exe utility are very vague, so call TI to get the specific parameters
> >> to produce a single output .hex file for your processor.
> >>
> >> R. Williams
> >> ---------- Original Message -----------
> >> From: William C Bonner
> >> To: Richard Williams
> >> Cc: l...@freenet.de, c...
> >> Sent: Tue, 08 May 2007 07:22:55 -0700
> >> Subject: Re: [c6x] how to load .out file from a running program
> >>
> >>
> >> > I have been interested in this sort of thing for a simple maintenence
> >> > program for a long time. I like your suggestion, and it leaves me with
> >> > a couple of questions.
> >> >
> >> > How do you create a .bin file?
> >> >
> >> > Is your .bin file relocatable after it's been created? Can you load the
> >> > file at an arbitrary location, and pass control to the correct offset,
> >> > and the program will do the standard C/C++ initialization and run main()?
> >> >
> >> > Wim.
> >> >
> >> > Richard Williams wrote:
> >> >
> >> > > I found that the linker info in the .out file makes it a very poor choice for loading.
> >> > >
> >> > > The best file format I have found is a .bin file, that is an image of what you want in memory.
> >> > > You need to know the entry offset in the file being loaded and the load address.
> >> > > Then it is a simple jump to the (load address + offset).
> >> > >
> >> > > ---------- Original Message -----------
> >> > > From: l...@freenet.de
> >> > > To: c...
> >> > > Sent: Mon, 07 May 2007 10:01:40 -0400
> >> > > Subject: [c6x] how to load .out file from a running program
> >> > >
> >> > >
> >> > >
> >> > > > hi,
> >> > > >
> >> > > > i use dsk6711 with network daughtercard and the network example Filexfer from ndk/examples,
> >> > > > i want that the running filexfer example loads a new .out file and stores it to the
> >> > > > sdram. And finally jump to the new .out file and run it.
> >> > > >
> >> > > > 1.do i have to load a .out-file or a .hex-file?
> >> > > > 2.how can i store it to a place in sdram?
> >> > > > 3.how can the dsp jump to the new .out-file and run it?
> >> > > >
> >> > > >