Suresh-
> I spoke to TI they have accepted that hex converter (hex6x) of TI seem to have some
> limitation that it cannot convert *.out greater than 512KB to hex properly (rather
> it overwrites ). be aware of this when burning your application on flash.

Thanks for this update. One thing you might try (or maybe you already did) is
removing all debug information from the .out file, which would make it smaller --
although not sure if the TI bug has to do with 512k of actual executable code or 512k
of overall file size. I think turning off global symbols in CCS is one part of this.
For production systems, that may be a good idea anyway to make it harder for a
competitor to reverse-engineer your code.

-Jeff
> suresh kirthi wrote:
>
> Jeff,
> Thank you Jeff.
> I'll elaborate on my problem:
>
> There was paging limitation of 512KB (though flash-memory is 4MB & this
> is due to address line limitation which are only 19 & rest 3bits are
> updated in FPGA page register )flashburn tool v2.8 provided by TI with
> CCS v 3.1 which I got it fixed by talking to the flashburn provider SDS.
> But I somehow feel even the hex6x tool of TI has similar limitation. And
> by the way I'am usin DM642 (720Mhz).
>
> I tried for the tool over the net to convert coff to hex but with
> hard-luck. But recently came to know about objcopy an utility of linux
> which does that conversion but still haven't tried it.
>
> I'am currently speaking to TI also.Incase there is any thing i'll keep
> the group posted.
> And in the meanwhile if anybody faced similar problem I would be grateful
> if you people could share your experience.
>
> thank you again,
> Suresh Kirthi,
> Kolkata.
>
> Jeff Brower wrote:
> Suresh-
>
> > Since the discussion was on bootloader & hex6x.exe I would like to
> > confirm from the group (jeff) whether hex6x has a limitation that it
> > won't convert coff files(*.out files) greater than 600KB(I think it is
> > 640KB) properly.
> >
> > Say for example if the coff file is around 1000KB approximates only the
>
> > last 400KB(1000KB - 640 KB) would be converted to hex .This probably
> the
> > first 640KB gets overwritten by the next. Even the map file show the
> > same observation.
>
> I haven't heard that one before, but wouldn't be surprised --
> unfortunately I've found and fought my way through lots of bugs in TI
> tools over the years before TI released fixed versions.
>
> My suggestions on this would be:
>
> -verify it's not intentional; for example maybe it's
> a limitation on the DSK version of tools; i.e. "non
> full version"
>
> -check with super experts on this group, including
> Mike Dunn, Bhooshan Iyer, and Andrew Nesterov --
> maybe they know about this bug. Bhoohsan is
> hooked up with latest TI tools version and errata
> info, so maybe he knows
>
> -try the latest version of hex6x.exe from CCS v3.1x.
> It would be unlikely this bug could live long with
> some of the big programs people must be putting
> together for 641x platforms
>
> -Jeff
>
> > Jeff Brower wrote:
> > Adeel Shahze-
> >
> > I would add to Skuzbary's comments that for the secondary bootloader,
> > there are lots
> > of app notes and source examples to follow given by TI for other DSPs.
> > Most of the
> > 54xx and 55xx families have very full-featured internal bootloaders
> stored
> > in
> > internal chip ROM, and tyically TI posts bootloader source code for
> those
> > devices
> > somewhere. The code is in asm, but typically almost commented
> > line-by-line.
> >
> > Also, whatever approach you take, I suggest you stay compatible with
> > hex6x.exe, which
> > is the standard TI utility for generating bootloadable files / images
> for
> > C6x
> > devices.
> >
> > -Jeff
> >
> > s...@tx.rr.com wrote:
> >>
> >> Greetings,
> >>
> >> It seems to me that you want to start your system booting from a
> device
> >> on the EMIF I/F.
> >>
> >> From C6713 data sheet, SPRS186J
> >>
> >> EMIF boot (using default ROM timings)
> >>
> >> Upon the release of internal reset, the 1K-Byte ROM code located in
> the
> >> beginning of CE1 is copied to address 0 by the EDMA using the default
> >> ROM timings, while the CPU is internally stalled. The data should be
>
> >> stored in the endian format that the system is using. The boot process
>
> >> also lets you choose the width of the ROM. In this case, the EMIF
> >> automatically assembles consecutive 8-bit bytes or 16-bit half-words
> to
> >> form the 32-bit instruction words to be copied. The transfer is
> >> automatically done by the EDMA as a single-frame block transfer from
> the
> >> ROM to address 0. After completion of the block transfer, the CPU is
> >> released from the stalled state and start running from address 0.
> >>
> >> Your code generation is capable of generating FLASH code that is
> >> compatible with this EMIF Boot using TI's COFF format.
> >>
> >> If you elect to write your own bootloader, which will be secondary
> >> bootloader, and will execute once the ROM bootloader copy it into
> >> internal RAM, then you can have a standard bitmap load stored in your
> >> FLASH, and you secondary bootloader will copy it to internal RAM, then
>
> >> give it control of the CPU.
> >>
> >> Good luck.
> >>
> >> hi
> >> >i hav givenn a task for writing bootloader for c6713 ,from flash rom
> at
> >> CE1 through EDMA
> >> >
> >> >Please guide me in
> >> >how to write bootloader???
> >> >
> >> >What setting are required in writing bootloader??
> >> >
> >> >What is algorithm of bootlaoding ???
> >> >
> >> >Sequence of operations needed by DSP after reset and power on related
>
> >> to bootloading????
>
> Regards,
>
> Suresh Kirthi..........
>
> "If a problem can be solved there is no use worrying about it. If it
> can't be solved, worrying will do no good."
> Regards,
> Suresh Kirthi.......... Start a New Thread

Jeff & 6x group,
I spoke to TI they have accepted that hex converter (hex6x) of TI seem to have some limitation that it cannot convert *.out greater than 512KB to hex properly (rather it overwrites ).

be aware of this when burning your application on flash.

thank you,
suresh kirthi
kolkata

suresh kirthi wrote:
Jeff,
Thank you Jeff.
I'll elaborate on my problem:

There was paging limitation of 512KB (though flash-memory is 4MB & this is due to address line limitation which are only 19 & rest 3bits are updated in FPGA page register )flashburn tool v2.8 provided by TI with CCS v 3.1 which I got it fixed by talking to the flashburn provider SDS. But I somehow feel even the hex6x tool of TI has similar limitation. And by the way I'am usin DM642 (720Mhz).

I tried for the tool over the net to convert coff to hex but with hard-luck. But recently came to know about objcopy an utility of linux which does that conversion but still haven't tried it.

I'am currently speaking to TI also.Incase there is any thing i'll keep the group posted.
And in the meanwhile if anybody faced similar problem I would be grateful if you people could share your experience.

thank you again,
Suresh Kirthi,
Kolkata.

Jeff Brower wrote:
Suresh-

> Since the discussion was on bootloader & hex6x.exe I would like to
> confirm from the group (jeff) whether hex6x has a limitation that it
> won't convert coff files(*.out files) greater than 600KB(I think it is
> 640KB) properly.
>
> Say for example if the coff file is around 1000KB approximates only the
> last 400KB(1000KB - 640 KB) would be converted to hex .This probably the
> first 640KB gets overwritten by the next. Even the map file show the
> same observation.

I haven't heard that one before, but wouldn't be surprised --
unfortunately I've found and fought my way through lots of bugs in TI
tools over the years before TI released fixed versions.

My suggestions on this would be:

-verify it's not intentional; for example maybe it's
a limitation on the DSK version of tools; i.e. "non
full version"

-check with super experts on this group, including
Mike Dunn, Bhooshan Iyer, and Andrew Nesterov --
maybe they know about this bug. Bhoohsan is
hooked up with latest TI tools version and errata
info, so maybe he knows

-try the latest version of hex6x.exe from CCS v3.1x.
It would be unlikely this bug could live long with
some of the big programs people must be putting
together for 641x platforms

-Jeff

> Jeff Brower wrote:
> Adeel Shahze-
>
> I would add to Skuzbary's comments that for the secondary bootloader,
> there are lots
> of app notes and source examples to follow given by TI for other DSPs.
> Most of the
> 54xx and 55xx families have very full-featured internal bootloaders stored
> in
> internal chip ROM, and tyically TI posts bootloader source code for those
> devices
> somewhere. The code is in asm, but typically almost commented
> line-by-line.
>
> Also, whatever approach you take, I suggest you stay compatible with
> hex6x.exe, which
> is the standard TI utility for generating bootloadable files / images for
> C6x
> devices.
>
> -Jeff
>
> s...@tx.rr.com wrote:
>>
>> Greetings,
>>
>> It seems to me that you want to start your system booting from a device
>> on the EMIF I/F.
>>
>> From C6713 data sheet, SPRS186J
>>
>> EMIF boot (using default ROM timings)
>>
>> Upon the release of internal reset, the 1K-Byte ROM code located in the
>> beginning of CE1 is copied to address 0 by the EDMA using the default
>> ROM timings, while the CPU is internally stalled. The data should be
>> stored in the endian format that the system is using. The boot process
>> also lets you choose the width of the ROM. In this case, the EMIF
>> automatically assembles consecutive 8-bit bytes or 16-bit half-words to
>> form the 32-bit instruction words to be copied. The transfer is
>> automatically done by the EDMA as a single-frame block transfer from the
>> ROM to address 0. After completion of the block transfer, the CPU is
>> released from the stalled state and start running from address 0.
>>
>> Your code generation is capable of generating FLASH code that is
>> compatible with this EMIF Boot using TI's COFF format.
>>
>> If you elect to write your own bootloader, which will be secondary
>> bootloader, and will execute once the ROM bootloader copy it into
>> internal RAM, then you can have a standard bitmap load stored in your
>> FLASH, and you secondary bootloader will copy it to internal RAM, then
>> give it control of the CPU.
>>
>> Good luck.
>>
>> hi
>> >i hav givenn a task for writing bootloader for c6713 ,from flash rom at
>> CE1 through EDMA
>> >
>> >Please guide me in
>> >how to write bootloader???
>> >
>> >What setting are required in writing bootloader??
>> >
>> >What is algorithm of bootlaoding ???
>> >
>> >Sequence of operations needed by DSP after reset and power on related
>> to bootloading????

Regards,

Suresh Kirthi..........

"If a problem can be solved there is no use worrying about it. If it can't be solved, worrying will do no good."

Regards,

Suresh Kirthi..........

"If a problem can be solved there is no use worrying about it. If it can't be solved, worrying will do no good."

---------------------------------
Everyone is raving about the all-new Yahoo! Mail beta. Start a New Thread

Suresh-
> Jeff,Thank you Jeff.I'll elaborate on my problem: There was paging limitation of
> 512KB (though flash-memory is 4MB & this is due to address line limitation which
> are only 19 & rest 3bits are updated in FPGA page register )flashburn tool v2.8
> provided by TI with CCS v 3.1 which I got it fixed by talking to the flashburn
> provider SDS. But I somehow feel even the hex6x tool of TI has similar limitation.
> And by the way I'am usin DM642 (720Mhz).

Ok, but these are separate issues, right? Whether hex6x.exe generates correct .rom
file is independent of which utility is used to actually write to Flash (Flashburn,
in-house, etc).
> I tried for the tool over the net to convert coff to hex but with hard-luck. But
> recently came to know about objcopy an utility of linux which does that conversion
> but still haven't tried it.

You might look for "TI COFF Loader" source code or similar; i.e. program that reads
.out file and loads to DSP memory. If you can find that source, then you can modify
to write data to binary or ASCII file.
> I'am currently speaking to TI also.Incase there is any thing i'll keep the group
> posted.And in the meanwhile if anybody faced similar problem I would be grateful if
> you people could share your experience.

If TI confirms a bug in hex6x, then yes please mention on the group. Could save
people a lot of time.

-Jeff
> Jeff Brower wrote:
>
> Suresh-
>
> > Since the discussion was on bootloader & hex6x.exe I would like to
> > confirm from the group (jeff) whether hex6x has a limitation that it
> > won't convert coff files(*.out files) greater than 600KB(I think it is
> > 640KB) properly.
> >
> > Say for example if the coff file is around 1000KB approximates only the
>
> > last 400KB(1000KB - 640 KB) would be converted to hex .This probably
> the
> > first 640KB gets overwritten by the next. Even the map file show the
> > same observation.
>
> I haven't heard that one before, but wouldn't be surprised --
> unfortunately I've found and fought my way through lots of bugs in TI
> tools over the years before TI released fixed versions.
>
> My suggestions on this would be:
>
> -verify it's not intentional; for example maybe it's
> a limitation on the DSK version of tools; i.e. "non
> full version"
>
> -check with super experts on this group, including
> Mike Dunn, Bhooshan Iyer, and Andrew Nesterov --
> maybe they know about this bug. Bhoohsan is
> hooked up with latest TI tools version and errata
> info, so maybe he knows
>
> -try the latest version of hex6x.exe from CCS v3.1x.
> It would be unlikely this bug could live long with
> some of the big programs people must be putting
> together for 641x platforms
>
> -Jeff
>
> > Jeff Brower wrote:
> > Adeel Shahze-
> >
> > I would add to Skuzbary's comments that for the secondary bootloader,
> > there are lots
> > of app notes and source examples to follow given by TI for other DSPs.
> > Most of the
> > 54xx and 55xx families have very full-featured internal bootloaders
> stored
> > in
> > internal chip ROM, and tyically TI posts bootloader source code for
> those
> > devices
> > somewhere. The code is in asm, but typically almost commented
> > line-by-line.
> >
> > Also, whatever approach you take, I suggest you stay compatible with
> > hex6x.exe, which
> > is the standard TI utility for generating bootloadable files / images
> for
> > C6x
> > devices.
> >
> > -Jeff
> >
> > s...@tx.rr.com wrote:
> >>
> >> Greetings,
> >>
> >> It seems to me that you want to start your system booting from a
> device
> >> on the EMIF I/F.
> >>
> >> From C6713 data sheet, SPRS186J
> >>
> >> EMIF boot (using default ROM timings)
> >>
> >> Upon the release of internal reset, the 1K-Byte ROM code located in
> the
> >> beginning of CE1 is copied to address 0 by the EDMA using the default
> >> ROM timings, while the CPU is internally stalled. The data should be
>
> >> stored in the endian format that the system is using. The boot process
>
> >> also lets you choose the width of the ROM. In this case, the EMIF
> >> automatically assembles consecutive 8-bit bytes or 16-bit half-words
> to
> >> form the 32-bit instruction words to be copied. The transfer is
> >> automatically done by the EDMA as a single-frame block transfer from
> the
> >> ROM to address 0. After completion of the block transfer, the CPU is
> >> released from the stalled state and start running from address 0.
> >>
> >> Your code generation is capable of generating FLASH code that is
> >> compatible with this EMIF Boot using TI's COFF format.
> >>
> >> If you elect to write your own bootloader, which will be secondary
> >> bootloader, and will execute once the ROM bootloader copy it into
> >> internal RAM, then you can have a standard bitmap load stored in your
> >> FLASH, and you secondary bootloader will copy it to internal RAM, then
>
> >> give it control of the CPU.
> >>
> >> Good luck.
> >>
> >> hi
> >> >i hav givenn a task for writing bootloader for c6713 ,from flash rom
> at
> >> CE1 through EDMA
> >> >
> >> >Please guide me in
> >> >how to write bootloader???
> >> >
> >> >What setting are required in writing bootloader??
> >> >
> >> >What is algorithm of bootlaoding ???
> >> >
> >> >Sequence of operations needed by DSP after reset and power on related
>
> >> to bootloading????
> Regards,
> Suresh Kirthi..........
> Start a New Thread

Jeff,
Thank you Jeff.
I'll elaborate on my problem:

There was paging limitation of 512KB (though flash-memory is 4MB & this is due to address line limitation which are only 19 & rest 3bits are updated in FPGA page register )flashburn tool v2.8 provided by TI with CCS v 3.1 which I got it fixed by talking to the flashburn provider SDS. But I somehow feel even the hex6x tool of TI has similar limitation. And by the way I'am usin DM642 (720Mhz).

I tried for the tool over the net to convert coff to hex but with hard-luck. But recently came to know about objcopy an utility of linux which does that conversion but still haven't tried it.

I'am currently speaking to TI also.Incase there is any thing i'll keep the group posted.
And in the meanwhile if anybody faced similar problem I would be grateful if you people could share your experience.

thank you again,
Suresh Kirthi,
Kolkata.

Jeff Brower wrote:
Suresh-

> Since the discussion was on bootloader & hex6x.exe I would like to
> confirm from the group (jeff) whether hex6x has a limitation that it
> won't convert coff files(*.out files) greater than 600KB(I think it is
> 640KB) properly.
>
> Say for example if the coff file is around 1000KB approximates only the
> last 400KB(1000KB - 640 KB) would be converted to hex .This probably the
> first 640KB gets overwritten by the next. Even the map file show the
> same observation.

I haven't heard that one before, but wouldn't be surprised --
unfortunately I've found and fought my way through lots of bugs in TI
tools over the years before TI released fixed versions.

My suggestions on this would be:

-verify it's not intentional; for example maybe it's
a limitation on the DSK version of tools; i.e. "non
full version"

-check with super experts on this group, including
Mike Dunn, Bhooshan Iyer, and Andrew Nesterov --
maybe they know about this bug. Bhoohsan is
hooked up with latest TI tools version and errata
info, so maybe he knows

-try the latest version of hex6x.exe from CCS v3.1x.
It would be unlikely this bug could live long with
some of the big programs people must be putting
together for 641x platforms

-Jeff

> Jeff Brower wrote:
> Adeel Shahze-
>
> I would add to Skuzbary's comments that for the secondary bootloader,
> there are lots
> of app notes and source examples to follow given by TI for other DSPs.
> Most of the
> 54xx and 55xx families have very full-featured internal bootloaders stored
> in
> internal chip ROM, and tyically TI posts bootloader source code for those
> devices
> somewhere. The code is in asm, but typically almost commented
> line-by-line.
>
> Also, whatever approach you take, I suggest you stay compatible with
> hex6x.exe, which
> is the standard TI utility for generating bootloadable files / images for
> C6x
> devices.
>
> -Jeff
>
> s...@tx.rr.com wrote:
>>
>> Greetings,
>>
>> It seems to me that you want to start your system booting from a device
>> on the EMIF I/F.
>>
>> From C6713 data sheet, SPRS186J
>>
>> EMIF boot (using default ROM timings)
>>
>> Upon the release of internal reset, the 1K-Byte ROM code located in the
>> beginning of CE1 is copied to address 0 by the EDMA using the default
>> ROM timings, while the CPU is internally stalled. The data should be
>> stored in the endian format that the system is using. The boot process
>> also lets you choose the width of the ROM. In this case, the EMIF
>> automatically assembles consecutive 8-bit bytes or 16-bit half-words to
>> form the 32-bit instruction words to be copied. The transfer is
>> automatically done by the EDMA as a single-frame block transfer from the
>> ROM to address 0. After completion of the block transfer, the CPU is
>> released from the stalled state and start running from address 0.
>>
>> Your code generation is capable of generating FLASH code that is
>> compatible with this EMIF Boot using TI's COFF format.
>>
>> If you elect to write your own bootloader, which will be secondary
>> bootloader, and will execute once the ROM bootloader copy it into
>> internal RAM, then you can have a standard bitmap load stored in your
>> FLASH, and you secondary bootloader will copy it to internal RAM, then
>> give it control of the CPU.
>>
>> Good luck.
>>
>> hi
>> >i hav givenn a task for writing bootloader for c6713 ,from flash rom at
>> CE1 through EDMA
>> >
>> >Please guide me in
>> >how to write bootloader???
>> >
>> >What setting are required in writing bootloader??
>> >
>> >What is algorithm of bootlaoding ???
>> >
>> >Sequence of operations needed by DSP after reset and power on related
>> to bootloading????

Regards,

Suresh Kirthi..........

"If a problem can be solved there is no use worrying about it. If it can't be solved, worrying will do no good." Start a New Thread

Since the discussion was on bootloader & hex6x.exe I would like to confirm from the group (jeff) whether hex6x has a limitation that it won't convert coff files(*.out files) greater than 600KB(I think it is 640KB) properly.

Say for example if the coff file is around 1000KB approximates only the last 400KB(1000KB - 640 KB) would be converted to hex .This probably the first 640KB gets overwritten by the next. Even the map file show the same observation.

thank you,
Suresh Kirthi,
Kolkata

Jeff Brower wrote:
Adeel Shahze-

I would add to Skuzbary's comments that for the secondary bootloader, there are lots
of app notes and source examples to follow given by TI for other DSPs. Most of the
54xx and 55xx families have very full-featured internal bootloaders stored in
internal chip ROM, and tyically TI posts bootloader source code for those devices
somewhere. The code is in asm, but typically almost commented line-by-line.

Also, whatever approach you take, I suggest you stay compatible with hex6x.exe, which
is the standard TI utility for generating bootloadable files / images for C6x
devices.

-Jeff

s...@tx.rr.com wrote:
>
> Greetings,
>
> It seems to me that you want to start your system booting from a device on the EMIF I/F.
>
> From C6713 data sheet, SPRS186J
>
> EMIF boot (using default ROM timings)
>
> Upon the release of internal reset, the 1K-Byte ROM code located in the beginning of CE1 is copied to address 0 by the EDMA using the default ROM timings, while the CPU is internally stalled. The data should be stored in the endian format that the system is using. The boot process also lets you choose the width of the ROM. In this case, the EMIF automatically assembles consecutive 8-bit bytes or 16-bit half-words to form the 32-bit instruction words to be copied. The transfer is automatically done by the EDMA as a single-frame block transfer from the ROM to address 0. After completion of the block transfer, the CPU is released from the stalled state and start running from address 0.
>
> Your code generation is capable of generating FLASH code that is compatible with this EMIF Boot using TI's COFF format.
>
> If you elect to write your own bootloader, which will be secondary bootloader, and will execute once the ROM bootloader copy it into internal RAM, then you can have a standard bitmap load stored in your FLASH, and you secondary bootloader will copy it to internal RAM, then give it control of the CPU.
>
> Good luck.
>
> hi
> >i hav givenn a task for writing bootloader for c6713 ,from flash rom at CE1 through EDMA
> >
> >Please guide me in
> >how to write bootloader???
> >
> >What setting are required in writing bootloader??
> >
> >What is algorithm of bootlaoding ???
> >
> >Sequence of operations needed by DSP after reset and power on related to bootloading????

Regards,

Suresh Kirthi..........

"If a problem can be solved there is no use worrying about it. If it can't be solved, worrying will do no good." Start a New Thread

Suresh-

> Since the discussion was on bootloader & hex6x.exe I would like to
> confirm from the group (jeff) whether hex6x has a limitation that it
> won't convert coff files(*.out files) greater than 600KB(I think it is
> 640KB) properly.
>
> Say for example if the coff file is around 1000KB approximates only the
> last 400KB(1000KB - 640 KB) would be converted to hex .This probably the
> first 640KB gets overwritten by the next. Even the map file show the
> same observation.

I haven't heard that one before, but wouldn't be surprised --
unfortunately I've found and fought my way through lots of bugs in TI
tools over the years before TI released fixed versions.

My suggestions on this would be:

-verify it's not intentional; for example maybe it's
a limitation on the DSK version of tools; i.e. "non
full version"

-check with super experts on this group, including
Mike Dunn, Bhooshan Iyer, and Andrew Nesterov --
maybe they know about this bug. Bhoohsan is
hooked up with latest TI tools version and errata
info, so maybe he knows

-try the latest version of hex6x.exe from CCS v3.1x.
It would be unlikely this bug could live long with
some of the big programs people must be putting
together for 641x platforms

-Jeff

> Jeff Brower wrote:
> Adeel Shahze-
>
> I would add to Skuzbary's comments that for the secondary bootloader,
> there are lots
> of app notes and source examples to follow given by TI for other DSPs.
> Most of the
> 54xx and 55xx families have very full-featured internal bootloaders stored
> in
> internal chip ROM, and tyically TI posts bootloader source code for those
> devices
> somewhere. The code is in asm, but typically almost commented
> line-by-line.
>
> Also, whatever approach you take, I suggest you stay compatible with
> hex6x.exe, which
> is the standard TI utility for generating bootloadable files / images for
> C6x
> devices.
>
> -Jeff
>
> s...@tx.rr.com wrote:
>>
>> Greetings,
>>
>> It seems to me that you want to start your system booting from a device
>> on the EMIF I/F.
>>
>> From C6713 data sheet, SPRS186J
>>
>> EMIF boot (using default ROM timings)
>>
>> Upon the release of internal reset, the 1K-Byte ROM code located in the
>> beginning of CE1 is copied to address 0 by the EDMA using the default
>> ROM timings, while the CPU is internally stalled. The data should be
>> stored in the endian format that the system is using. The boot process
>> also lets you choose the width of the ROM. In this case, the EMIF
>> automatically assembles consecutive 8-bit bytes or 16-bit half-words to
>> form the 32-bit instruction words to be copied. The transfer is
>> automatically done by the EDMA as a single-frame block transfer from the
>> ROM to address 0. After completion of the block transfer, the CPU is
>> released from the stalled state and start running from address 0.
>>
>> Your code generation is capable of generating FLASH code that is
>> compatible with this EMIF Boot using TI's COFF format.
>>
>> If you elect to write your own bootloader, which will be secondary
>> bootloader, and will execute once the ROM bootloader copy it into
>> internal RAM, then you can have a standard bitmap load stored in your
>> FLASH, and you secondary bootloader will copy it to internal RAM, then
>> give it control of the CPU.
>>
>> Good luck.
>>
>> hi
>> >i hav givenn a task for writing bootloader for c6713 ,from flash rom at
>> CE1 through EDMA
>> >
>> >Please guide me in
>> >how to write bootloader???
>> >
>> >What setting are required in writing bootloader??
>> >
>> >What is algorithm of bootlaoding ???
>> >
>> >Sequence of operations needed by DSP after reset and power on related
>> to bootloading???? Start a New Thread

Greetings,

Here is an example done for the 6xxx, which is applicable tour your case too. You may need to mod the addresses for your device and memory map.

;EMIFA Register Addresses for c6xxx family
EMIFA_GCTL .equ 0x01800000 ;EMIFA global control
EMIFA_CE1 .equ 0x01800004 ;EMIFA CE1 control
; EMIFA Register Values specifically for Custom Board
EMIFA_GCTL_V .equ 0x00012778 ;
EMIFA_CE1_V .equ 0x42A4CA02 ;EMIFA CE1 default value

unused .macro id
.global unused:id:
unused:id:
b unused:id: ; nested branches to block interrupts
nop 4
nop
nop
nop
nop
nop
nop
.endm

.ref _c_int00
.global RESET_RST

FLASH_START .equ 0x90000400 ;flash start address
CODE_START .equ 0x00000400 ;start of boot code
CODE_SIZE .equ 0x00003BF8 ;boot code size in byte

.sect "vectors"
RESET_RST:
mvkl .S2 _boot_start, B0
mvkh .S2 _boot_start, B0
B .S2 B0
NOP
NOP
NOP
NOP
NOP

unused 1
unused 2
unused 3
unused 4
unused 5
unused 6
unused 7
unused 8
unused 9
unused 10
unused 11
unused 12
unused 13
unused 14
unused 15

.sect "bootload"

_boot_start:

;disable global interrupts
mvc.s2 CSR,B4
and.d2 -2,B4,B4
mvc.s2 B4,CSR
nop

;****************************************************************
; *EMIFA_GCTL = EMIFA_GCTL_V;
;****************************************************************

mvkl EMIFA_GCTL,A4
|| mvkl EMIFA_GCTL_V,B4

mvkh EMIFA_GCTL,A4
|| mvkh EMIFA_GCTL_V,B4

stw B4,*A4
;****************************************************************
; *EMIFA_CE1 = EMIFA_CE1_V (not used)
;****************************************************************

mvkl EMIFA_CE1,A4
|| mvkl EMIFA_CE1_V,B4

mvkh EMIFA_CE1,A4
|| mvkh EMIFA_CE1_V,B4

stw B4,*A4

mvkl FLASH_START,B4 ;flash start address ->B4
mvkh FLASH_START,B4

mvkl CODE_START,A4 ;apps code start address ->A4
mvkh CODE_START,A4
zero A1

_boot_loop1:
ldb *B4++,B5 ; flash read
mvkl CODE_SIZE,B6 ; B6 = BOOT_SIZE

add 1,A1,A1 ;A1+=1,inc outer counter
|| mvkh CODE_SIZE,B6

cmplt A1,B6,B0
nop
stb B5,*A4++
[B0]b _boot_loop1
nop 5

mvkl .S2 _c_int00, B0
mvkh .S2 _c_int00, B0
B .S2 B0
nop 5

Good luck
Adeel Shahze-
>
>I would add to Skuzbary's comments that for the secondary bootloader, there are lots
>of app notes and source examples to follow given by TI for other DSPs. Most of the
>54xx and 55xx families have very full-featured internal bootloaders stored in
>internal chip ROM, and tyically TI posts bootloader source code for those devices
>somewhere. The code is in asm, but typically almost commented line-by-line.
>
>Also, whatever approach you take, I suggest you stay compatible with hex6x.exe, which
>is the standard TI utility for generating bootloadable files / images for C6x
>devices.
>
>-Jeff
>
>s...@tx.rr.com wrote:
>>
>> Greetings,
>>
>> It seems to me that you want to start your system booting from a device on the EMIF I/F.
>>
>> From C6713 data sheet, SPRS186J
>>
>> EMIF boot (using default ROM timings)
>>
>> Upon the release of internal reset, the 1K-Byte ROM code located in the beginning of CE1 is copied to address 0 by the EDMA using the default ROM timings, while the CPU is internally stalled. The data should be stored in the endian format that the system is using. The boot process also lets you choose the width of the ROM. In this case, the EMIF automatically assembles consecutive 8-bit bytes or 16-bit half-words to form the 32-bit instruction words to be copied. The transfer is automatically done by the EDMA as a single-frame block transfer from the ROM to address 0. After completion of the block transfer, the CPU is released from the stalled state and start running from address 0.
>>
>> Your code generation is capable of generating FLASH code that is compatible with this EMIF Boot using TI's COFF format.
>>
>> If you elect to write your own bootloader, which will be secondary bootloader, and will execute once the ROM bootloader copy it into internal RAM, then you can have a standard bitmap load stored in your FLASH, and you secondary bootloader will copy it to internal RAM, then give it control of the CPU.
>>
>> Good luck.
>>
>> hi
>> > i hav givenn a task for writing bootloader for c6713 ,from flash rom at CE1 through EDMA
>> >
>> > Please guide me in
>> > how to write bootloader???
>> >
>> > What setting are required in writing bootloader??
>> >
>> > What is algorithm of bootlaoding ???
>> >
>> > Sequence of operations needed by DSP after reset and power on related to bootloading???? Start a New Thread

Adeel Shahze-

I would add to Skuzbary's comments that for the secondary bootloader, there are lots
of app notes and source examples to follow given by TI for other DSPs. Most of the
54xx and 55xx families have very full-featured internal bootloaders stored in
internal chip ROM, and tyically TI posts bootloader source code for those devices
somewhere. The code is in asm, but typically almost commented line-by-line.

Also, whatever approach you take, I suggest you stay compatible with hex6x.exe, which
is the standard TI utility for generating bootloadable files / images for C6x
devices.

-Jeff

s...@tx.rr.com wrote:
>
> Greetings,
>
> It seems to me that you want to start your system booting from a device on the EMIF I/F.
>
> From C6713 data sheet, SPRS186J
>
> EMIF boot (using default ROM timings)
>
> Upon the release of internal reset, the 1K-Byte ROM code located in the beginning of CE1 is copied to address 0 by the EDMA using the default ROM timings, while the CPU is internally stalled. The data should be stored in the endian format that the system is using. The boot process also lets you choose the width of the ROM. In this case, the EMIF automatically assembles consecutive 8-bit bytes or 16-bit half-words to form the 32-bit instruction words to be copied. The transfer is automatically done by the EDMA as a single-frame block transfer from the ROM to address 0. After completion of the block transfer, the CPU is released from the stalled state and start running from address 0.
>
> Your code generation is capable of generating FLASH code that is compatible with this EMIF Boot using TI's COFF format.
>
> If you elect to write your own bootloader, which will be secondary bootloader, and will execute once the ROM bootloader copy it into internal RAM, then you can have a standard bitmap load stored in your FLASH, and you secondary bootloader will copy it to internal RAM, then give it control of the CPU.
>
> Good luck.
>
> hi
> >i hav givenn a task for writing bootloader for c6713 ,from flash rom at CE1 through EDMA
> >
> >Please guide me in
> >how to write bootloader???
> >
> >What setting are required in writing bootloader??
> >
> >What is algorithm of bootlaoding ???
> >
> >Sequence of operations needed by DSP after reset and power on related to bootloading???? Start a New Thread

Greetings,

It seems to me that you want to start your system booting from a device on the EMIF I/F.

>From C6713 data sheet, SPRS186J

EMIF boot (using default ROM timings)

Upon the release of internal reset, the 1K-Byte ROM code located in the beginning of CE1 is copied to address 0 by the EDMA using the default ROM timings, while the CPU is internally stalled. The data should be stored in the endian format that the system is using. The boot process also lets you choose the width of the ROM. In this case, the EMIF automatically assembles consecutive 8-bit bytes or 16-bit half-words to form the 32-bit instruction words to be copied. The transfer is automatically done by the EDMA as a single-frame block transfer from the ROM to address 0. After completion of the block transfer, the CPU is released from the stalled state and start running from address 0.

Your code generation is capable of generating FLASH code that is compatible with this EMIF Boot using TI's COFF format.

If you elect to write your own bootloader, which will be secondary bootloader, and will execute once the ROM bootloader copy it into internal RAM, then you can have a standard bitmap load stored in your FLASH, and you secondary bootloader will copy it to internal RAM, then give it control of the CPU.

Good luck.
hi
>i hav givenn a task for writing bootloader for c6713 ,from flash rom at CE1 through EDMA
>
>Please guide me in
>how to write bootloader???
>
>What setting are required in writing bootloader??
>
>What is algorithm of bootlaoding ???
>
>Sequence of operations needed by DSP after reset and power on related to bootloading???? Start a New Thread

I believe that I know some of the things that would be involved, and
would be interested in having source for my own personal boot loader,
but I don't have time to write my own just now.

Steps I'd like my boot loader to do.

1. initialize the basic hardware setup. (RAM access and Flash Access)
2. verify a valid COFF object file exists in flash.
3. load a COFF file from flash into RAM, interpreting all of the
relocation entries correctly and adjusting them as needed.
4. transfer control to the loaded image.

That's what I believe I'd like a boot loader to do. As an extension I
want the boot loader to be able to do the following:

* Failing to find a valid image in flash, attempt to transfer a
valid image via a verified transport over either a serial port or
a network port, either loading directly into ram and transferring
control, or writing to flash and then starting the sequence from
the time. (When I say verified transport I mean something like
Xmodem / Ymodem / Zmodem that uses block checking via CRCs on the
whole file, so that control wouldn't be transferred until the
whole image was verified as being transferred.)
* allow choosing from multiple images in flash.

After listing my collection of "wants" I'm interested in knowing how
much of what I want normally falls into what a boot loader does?

a...@gmail.com wrote:
> hi
> i hav givenn a task for writing bootloader for c6713 ,from flash rom at CE1 through EDMA
>
> Please guide me in
> how to write bootloader???
>
> What setting are required in writing bootloader??
>
> What is algorithm of bootlaoding ???
>
> Sequence of operations needed by DSP after reset and power on related to bootloading????
> Start a New Thread