William-

I think it's the sort of thing that gets done often enough, but complex
enough that people won't give many details about it on tech groups.

We use the hex6x utility to take .out files and generate ".rom" files
which are basically some number of sections with simple "address, length,
data" structure that contain the executable binary code image. The hex6x
output format is simple and it's straightforward to find contiguous
records and concatenate to make the .rom file sections. Then we write
Flash with the .rom file -- in some cases using PC bus access to the
Flash, in other cases via network or RS-422. Usually we have a simple DMA
controller or microcontroller in logic (FPGA) on the board that transfers
the Flash contents to DSP memory via HPI at boot-time then runs the DSP.

This approach is flexible: doesn't matter how the data got in Flash or
when, kills the need for the "small bootloader code thing" and its various
limitations, doesn't tie us to CCS and FlashBurn etc, allows us to give
the DSP new code while it's running if necessary, and allows multiple
images to be stored in Flash.

-Jeff

> This is all over the serial communication port. I'm actually using
> RS422 instead of RS232, it works over significantly longer distance, but
> does not have out of band flow control signaling.
>
> Hex is fine for me, instead of .out. I'm currently flashing my machine
> by transferring a hex file to it using a third party bios. I'm not
> satisfied with this solution, because the bios only uses XON/XOFF Flow
> control, and I have managed to send it hex files that got burned to
> flash even after corrupting during the transfer. At that point I had a
> board that I could only control by physically dropping the RESET / SET
> lines.
>
> I have implemented a zmodem transfer to reliably transfer binary data to
> and from the DSP board. It should work just fine for ascii transfers as
> well. It uses either a 16 bit or 32 bit CRC, and has the ability to
> back up and retransmit sections of the file that did not pass the CRC
> check. I liked ZModem, because It was designed to work as a streaming
> protocol, but seemed to have robust data correction, as well as data
> recognition. Running over rs422 at either 115200kpbs or 460800kpbs the
> error correction is important to me.
>
> My current method uploads using a Hex file labeled as an Intel Hex File.
>
> Does the hex file only reference FLASH Ram locations? I'm trying to
> understand about interpreting the HEX file to write the data to the
> flash. http://www.keil.com/support/docs/1584.htm has an easy to read
> discussion about hex files.
>
> I guess my easy to ask question would be if I could interpret the HEX
> file on the PC, and encode the data into 64k binary files that would
> match the 64 k sector sizes of my flash. That leads directly to
> transferring the flash sectors in binary, and flashing complete sectors
> to the flash.
>
> What I'd really like to do is to have a small program that when compiled
> fits int a single sector of flash. My processor boot load sequence
> would have the bios do it's thing, call my boot loader which would check
> to see if a valid program was in flash, and load it if it was, or
> request a fiel download over the serial port if the program in flash
> wasn't valid.
>
> Actually I just thought of one of the original reasons I wanted this to
> work, which was to be able to bypass loading new code into flash on a
> regular basis. I wanted the ability to build my code, and transfer it
> to the running process via serial, and then transfer control to it in ram.
>
> Are the thoughts that I was following really complicated and out of the
> ordinary? Or are they fairly standard and someone else has implemented
> this and I'm just not using the right keywords to search for it?
>
> Thanks.. Wim.
>
> Mike Dunn wrote:
>> --- tien vuong wrote:
>>> --- William C Bonner wrote:
>>>
>>>
>>>> I want to build a program to run on my DSP that will securely download
>>>> a
>>>> .out file and then pass control to it. What I really want to do is
>>>> to
>>>> be able to download the coff file and after verifyling that I've got
>>>> the
>>>> segments correctly downloaded with CRCs burn it into my flash.
>>>>
>>> Do you download over rs232? Converting .out to Intel
>>> hex format and using ASCII transfer would work for
>>> you. TI provides a convert utility to do that.
>>>
>> The hex6x utility is probably the way to go. Ti's
>> COFF format has quite a bit of debug and relocation
>> info that makes it a minor pain to parse. I would
>> suggest using hex6x, which will give you a file that
>> looks like the old Mot or Intel 'EPROM programming
>> format' [originally designed to be 'paper tape
>> friendly' - it sends info as
>> add-data-...-data-checksum]. This format is ASCII
>> based and has 2 minor problems for downloading - [1]
>> 100+% overhead and [2] 'mickey mouse' checksums. You
>> can solve #1 [if it is a problem] by coverting the
>> ASCII to hex [ie, instead of sending 0x34 for the
>> number 4, you send 4 bits 0100b]. You can solve #2 by
>> wrapping transmit blocks in a simplified block
>> protocol [I have used a simplified version of the old
>> IBM 2780 protocol that forces the target to ACK or NAK
>> each block based on a CRC check of the data].
>>
>> mikedunn
>>
>>>> Can anyone point me to resources on the net that would help me get
>>>> started on this project? I've got my transport protocol figured out,
>>>> and can transfer files back and forth at high speed,
>>>>
>>>> I just don't know how I should arrange the coff file in flash so I can
>>>>
>>>> transfer control.
>>>>
>>>> Wim.
>>>>
>>> Once using TI hex converter, your output hex file will
>>> contain info about what address in flash to store data.

This is all over the serial communication port. I'm actually using
RS422 instead of RS232, it works over significantly longer distance, but
does not have out of band flow control signaling.

Hex is fine for me, instead of .out. I'm currently flashing my machine
by transferring a hex file to it using a third party bios. I'm not
satisfied with this solution, because the bios only uses XON/XOFF Flow
control, and I have managed to send it hex files that got burned to
flash even after corrupting during the transfer. At that point I had a
board that I could only control by physically dropping the RESET / SET
lines.

I have implemented a zmodem transfer to reliably transfer binary data to
and from the DSP board. It should work just fine for ascii transfers as
well. It uses either a 16 bit or 32 bit CRC, and has the ability to
back up and retransmit sections of the file that did not pass the CRC
check. I liked ZModem, because It was designed to work as a streaming
protocol, but seemed to have robust data correction, as well as data
recognition. Running over rs422 at either 115200kpbs or 460800kpbs the
error correction is important to me.

My current method uploads using a Hex file labeled as an Intel Hex File.

Does the hex file only reference FLASH Ram locations? I'm trying to
understand about interpreting the HEX file to write the data to the
flash. http://www.keil.com/support/docs/1584.htm has an easy to read
discussion about hex files.

I guess my easy to ask question would be if I could interpret the HEX
file on the PC, and encode the data into 64k binary files that would
match the 64 k sector sizes of my flash. That leads directly to
transferring the flash sectors in binary, and flashing complete sectors
to the flash.

What I'd really like to do is to have a small program that when compiled
fits int a single sector of flash. My processor boot load sequence
would have the bios do it's thing, call my boot loader which would check
to see if a valid program was in flash, and load it if it was, or
request a fiel download over the serial port if the program in flash
wasn't valid.

Actually I just thought of one of the original reasons I wanted this to
work, which was to be able to bypass loading new code into flash on a
regular basis. I wanted the ability to build my code, and transfer it
to the running process via serial, and then transfer control to it in ram.

Are the thoughts that I was following really complicated and out of the
ordinary? Or are they fairly standard and someone else has implemented
this and I'm just not using the right keywords to search for it?

Thanks.. Wim.

Mike Dunn wrote:
> --- tien vuong wrote:
>
>
>> --- William C Bonner wrote:
>>
>>
>>> I want to build a program to run on my DSP that will securely download a
>>> .out file and then pass control to it. What I really want to do is to
>>> be able to download the coff file and after verifyling that I've got the
>>> segments correctly downloaded with CRCs burn it into my flash.
>>>
>> Do you download over rs232? Converting .out to Intel
>> hex format and using ASCII transfer would work for
>> you. TI provides a convert utility to do that.
>>
> The hex6x utility is probably the way to go. Ti's
> COFF format has quite a bit of debug and relocation
> info that makes it a minor pain to parse. I would
> suggest using hex6x, which will give you a file that
> looks like the old Mot or Intel 'EPROM programming
> format' [originally designed to be 'paper tape
> friendly' - it sends info as
> add-data-...-data-checksum]. This format is ASCII
> based and has 2 minor problems for downloading - [1]
> 100+% overhead and [2] 'mickey mouse' checksums. You
> can solve #1 [if it is a problem] by coverting the
> ASCII to hex [ie, instead of sending 0x34 for the
> number 4, you send 4 bits 0100b]. You can solve #2 by
> wrapping transmit blocks in a simplified block
> protocol [I have used a simplified version of the old
> IBM 2780 protocol that forces the target to ACK or NAK
> each block based on a CRC check of the data].
>
> mikedunn
>
>>> Can anyone point me to resources on the net that would help me get
>>> started on this project? I've got my transport protocol figured out,
>>> and can transfer files back and forth at high speed,
>>>
>>> I just don't know how I should arrange the coff file in flash so I can
>>>
>>> transfer control.
>>>
>>> Wim.
>>>
>> Once using TI hex converter, your output hex file will
>> contain info about what address in flash to store data.
>>

Wim,

--- tien vuong wrote:

> Hi William,
>
> --- William C Bonner wrote:
>
> > I want to build a program to run on my DSP that
> will
> > securely download a
> > .out file and then pass control to it. What I
> > really want to do is to
> > be able to download the coff file and after
> > verifyling that I've got the
> > segments correctly downloaded with CRCs burn it
> into
> > my flash.
>
> Do you download over rs232? Converting .out to Intel
> hex format and using ASCII transfer would work for
> you. TI provides a convert utility to do that.
The hex6x utility is probably the way to go. Ti's
COFF format has quite a bit of debug and relocation
info that makes it a minor pain to parse. I would
suggest using hex6x, which will give you a file that
looks like the old Mot or Intel 'EPROM programming
format' [originally designed to be 'paper tape
friendly' - it sends info as
add-data-...-data-checksum]. This format is ASCII
based and has 2 minor problems for downloading - [1]
100+% overhead and [2] 'mickey mouse' checksums. You
can solve #1 [if it is a problem] by coverting the
ASCII to hex [ie, instead of sending 0x34 for the
number 4, you send 4 bits 0100b]. You can solve #2 by
wrapping transmit blocks in a simplified block
protocol [I have used a simplified version of the old
IBM 2780 protocol that forces the target to ACK or NAK
each block based on a CRC check of the data].

mikedunn
>
> >
> > Can anyone point me to resources on the net that
> > would help me get
> > started on this project? I've got my transport
> > protocol figured out,
> > and can transfer files back and forth at high
> speed,
> > I just don't know
> > how I should arrange the coff file in flash so I
> can
> > transfer control.
> >
> > Wim.
>
> Once using TI hex converter, your output hex file
> will
> contain info about what address in flash to store
> data.
>
> __________________________________________________
>
>
> c...
>
>
>

Hi William,

--- William C Bonner wrote:

> I want to build a program to run on my DSP that will
> securely download a
> .out file and then pass control to it. What I
> really want to do is to
> be able to download the coff file and after
> verifyling that I've got the
> segments correctly downloaded with CRCs burn it into
> my flash.

Do you download over rs232? Converting .out to Intel
hex format and using ASCII transfer would work for
you. TI provides a convert utility to do that.

>
> Can anyone point me to resources on the net that
> would help me get
> started on this project? I've got my transport
> protocol figured out,
> and can transfer files back and forth at high speed,
> I just don't know
> how I should arrange the coff file in flash so I can
> transfer control.
>
> Wim.

Once using TI hex converter, your output hex file will
contain info about what address in flash to store data.

__________________________________________________

I want to build a program to run on my DSP that will securely download a
.out file and then pass control to it. What I really want to do is to
be able to download the coff file and after verifyling that I've got the
segments correctly downloaded with CRCs burn it into my flash.

Can anyone point me to resources on the net that would help me get
started on this project? I've got my transport protocol figured out,
and can transfer files back and forth at high speed, I just don't know
how I should arrange the coff file in flash so I can transfer control.

Wim.