AD535 | BIOS | Booting | Bootloader | C621 | C6211 | C6415 | C671 | C6711 | C6711DSK | C6713 | CCS | Chassaing | COFF | DAT | DM64 | DM642 | DMA | DSK671 | DSK6711 | EDM | EDMA | EMIF | Emulator | EVM | EVM620 | FFT | FIR | GPIO | Halting | HPI | HWI | IDK | JTAG | LDB | LDH | LDW | Linker | LMS | LOG_printf | Matlab | McBSP | MEM_alloc | MIPS | PCI | PCM3003 | Pipeline | Profiling | QDM | Reset | ROM | RTDX | Sampling | SDRAM | Stack | TEB | THS1206 | TMS320C621 | TMS320C6416 | TMS320C6711 | TMS320C6713 | UART | Vector Table | XBUS | XDS560

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.

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Hi William,

--- William C Bonner <w...@wimsworld.com> 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.

__________________________________________________

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Wim,

--- tien vuong <v...@yahoo.com> wrote:

> Hi William,
> 
> --- William C Bonner <w...@wimsworld.com> 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...@yahoogroups.com
> 
>  
>

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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 <v...@yahoo.com> wrote:
>
>   
>> --- William C Bonner <w...@wimsworld.com> 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.
>>

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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 <v...@yahoo.com> wrote:
>>> --- William C Bonner <w...@wimsworld.com> 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.

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )