BOOT LOADER

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