AIC23 | C5509 | CCS | CSL | EMIF | EVM | GEL | GPIO | HPI | Interfacing | JTAG | McBSP | OMAP | Omap15 | OMAP59 | RTDX | SDRAM | TMS320VC5509 | USB | XDS5

Jeff > boot table. Then store the .rom file in your EEPROM by parsing the address > and data. What exactly do u mean by parsing ? Is .rom file needs to interpreted for that ? Anand. ----- Original Message ----- From: <> To: <> Sent: Tuesday, January 06, 2004 11:00 PM Subject: [c55x] Digest Number 199 > There are 5 messages in this issue. > > Topics in this digest: > > 1. External Flash Boot > From: "ajmassa" <> > 2. Re: External Flash Boot > From: Jeff Brower <> > 3. Re: problems while emulating DSK5510 with code composer > From: "sks_dsp" <> > 4. Re: External Flash Boot > From: "sks_dsp" <> > 5. Re: External Flash Boot > From: Indrek Rebane < > ________________________________________________________________________ > ________________________________________________________________________ > > Message: 1 > Date: Mon, 05 Jan 2004 18:11:43 -0000 > From: "ajmassa" <> > Subject: External Flash Boot > I have a custom board that I want to boot from external flash. I am > using a c5509. I do not want to use a boot table, I just want to > directly execute from flash after the DSP comes out of reset. Does > anyone have a (detailed) sequence of steps to do this that they have > successfully verified - from the building of the application (such as > linker options), to the conversion of the .out file, to the > application used to burn the flash, etc. > > Thanks. > > > ________________________________________________________________________ > ________________________________________________________________________ > > Message: 2 > Date: Mon, 05 Jan 2004 12:53:06 -0600 > From: Jeff Brower <> > Subject: Re: External Flash Boot > > AJ Massa- > > > I have a custom board that I want to boot from external flash. I am > > using a c5509. I do not want to use a boot table, I just want to > > directly execute from flash after the DSP comes out of reset. Does > > anyone have a (detailed) sequence of steps to do this that they have > > successfully verified - from the building of the application (such as > > linker options), to the conversion of the .out file, to the > > application used to burn the flash, etc. > > Use hex500 utility with -x and -romwidth 16 options to create a .rom file with no > boot table. Then store the .rom file in your EEPROM by parsing the address and > data. This will essentially create an image in your EEPROM that matches what CCS > would have done by downloading the .out file to SRAM. > > The linker should be set for run-time initialization. > > It's very simple, you can't miss. > > -Jeff > ________________________________________________________________________ > ________________________________________________________________________ > > Message: 3 > Date: Tue, 06 Jan 2004 14:24:26 -0000 > From: "sks_dsp" <> > Subject: Re: problems while emulating DSK5510 with code composer > > Sounds like a classic pipeline latency/conflict problem. Somewhere > you have an instruction whose result is being used before it is > ready. When single stepping, the software TRAP that the emulator > inserts creates enough "latency" and the result appears to be > correct. But when running straight through the operation will be > incorrect. > > Look for instructions that are known to have latency issues and add a > few NOPs after them. Or insert NOPS here and there and retest. > > -Shawn > www.appliedsignalprocessing.com > --- In , "maxisonnaillon" <maxisonnaillon@y...> > wrote: > > While I emulate an example of the Image Library (quantize) I get > > wrong results if i run the program at once, but if i run it step by > > step, the program works right. > > Do anyone know what could be the problem? > > Thanx > > Maximiliano Sonnaillon > > > ________________________________________________________________________ > ________________________________________________________________________ > > Message: 4 > Date: Tue, 06 Jan 2004 14:31:35 -0000 > From: "sks_dsp" <> > Subject: Re: External Flash Boot > > We have a "loader applet" that allows dsp applications to be burned > to the FLASH on the target hardware over a serial link: > > http://www.appliedsignalprocessing.com/tidsp.htm > > We've done this for a 5510. We normally use boot records, but I'm > sure we could customize it for your application. Contact us. > > -Shawn Steenhagen > www.appliedsignalprocessing.com > --- In , "ajmassa" <amassa@s...> wrote: > > > > I have a custom board that I want to boot from external flash. I > am > > using a c5509. I do not want to use a boot table, I just want to > > directly execute from flash after the DSP comes out of reset. Does > > anyone have a (detailed) sequence of steps to do this that they > have > > successfully verified - from the building of the application (such > as > > linker options), to the conversion of the .out file, to the > > application used to burn the flash, etc. > > > > Thanks. > > > ________________________________________________________________________ > ________________________________________________________________________ > > Message: 5 > Date: Tue, 06 Jan 2004 16:42:33 +0200 > From: Indrek Rebane <> > Subject: Re: External Flash Boot > > ajmassa wrote: > > I have a custom board that I want to boot from external flash. > > I am using a c5509. I do not want to use a boot table, I just > > want to directly execute from flash after the DSP comes out of > > reset. > > Might not be so wise thing to do for sake of performance. Flash > memory is usually quite slow (>70ns access) which will hold up > execution of code (vs. 5ns on SARAM@200MHz, C5509A assumed). Also, > when EMIF is used for accessing something else those other > accesses might get slow. Extreme case being programming same flash > chip which might get system to deadlock. > > Indrek > > -- > Indrek Rebane | Borthwick-Pignon > Electronics Engineer | Tartu Science Park > Phone: (+372) 7 302 641 | Riia 185, 51014 Tartu > Fax: (+372) 7 383 041 | Estonia > | www.bps.co.ee > > > ________________________________________________________________________ > ________________________________________________________________________ > _____________________________________ > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



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

Anand- > > boot table. Then store the .rom file in your EEPROM by parsing the > > address and data. > > What exactly do u mean by parsing ? Is .rom file needs to interpreted for > that ? The .rom file looks something like: hdr,addr0,count0,data[0],data[1]...data[count0-1] hdr,addr1,count1,data[0],data[1]...data[count1-1] . . . hdr,addrN,countN,data[0],data[1]...data[countN-1] hdr,addr,0 so you have to 'parse' this to load the executable binary image; i.e. i = 0; do { hdr1 = get_rom_file_parm(); // stuff you might or might not use hdr2 = get_rom_file_parm(); . . . write_eeprom(i++, get_rom_file_parm()); write_eeprom(i++, count = get_rom_file_parm()); for (j=0; j<count; j++) write_eeprom(i++, get_rom_file_parm()); } while (!eof); Then you can later read from EEPROM and write to DSP mem: i = 0; do { addr = read_eeprom(i++); count = read_eeprom(i++); for (j=0; j<count; j++) write_dspmem(addr++, read_eeprom(i++)); } while (count != 0); If you want to save EEPROM space and reduce overhead, then you can make the .rom file reader smarter so it groups individual address lines together when they are contiguous, and reduce the number of "sections" in EEPROM to the mininum needed (ie only those sections with non-contiguous start address). Note that C5xxx onchip bootloaders do something like the above when you use -boot options in hex500. That is intended for booting through a peripheral other than HPI, such as McBSP, EMIF, I/O, etc. For what AJ Massa wanted to do (execute from EEPROM directly), he would combine the two steps above: parse the .rom file, store results temporarily, write to EEPROM. Of course -- as pointed out so colorfully by other group members -- his problem will be that the EEPROM can be very slow and even maximum number of wait-states might not save him unless he decreases the processor clock :-) -Jeff > ----- Original Message ----- > From: <> > To: <> > Sent: Tuesday, January 06, 2004 11:00 PM > Subject: [c55x] Digest Number 199 > > > There are 5 messages in this issue. > > > > Topics in this digest: > > > > 1. External Flash Boot > > From: "ajmassa" <> > > 2. Re: External Flash Boot > > From: Jeff Brower <> > > 3. Re: problems while emulating DSK5510 with code composer > > From: "sks_dsp" <> > > 4. Re: External Flash Boot > > From: "sks_dsp" <> > > 5. Re: External Flash Boot > > From: Indrek Rebane <> > > > > > > ________________________________________________________________________ > > ________________________________________________________________________ > > > > Message: 1 > > Date: Mon, 05 Jan 2004 18:11:43 -0000 > > From: "ajmassa" <> > > Subject: External Flash Boot > > > > > > I have a custom board that I want to boot from external flash. I am > > using a c5509. I do not want to use a boot table, I just want to > > directly execute from flash after the DSP comes out of reset. Does > > anyone have a (detailed) sequence of steps to do this that they have > > successfully verified - from the building of the application (such as > > linker options), to the conversion of the .out file, to the > > application used to burn the flash, etc. > > > > Thanks. > > > > > > > > > > ________________________________________________________________________ > > ________________________________________________________________________ > > > > Message: 2 > > Date: Mon, 05 Jan 2004 12:53:06 -0600 > > From: Jeff Brower <> > > Subject: Re: External Flash Boot > > > > AJ Massa- > > > > > I have a custom board that I want to boot from external flash. I am > > > using a c5509. I do not want to use a boot table, I just want to > > > directly execute from flash after the DSP comes out of reset. Does > > > anyone have a (detailed) sequence of steps to do this that they have > > > successfully verified - from the building of the application (such as > > > linker options), to the conversion of the .out file, to the > > > application used to burn the flash, etc. > > > > Use hex500 utility with -x and -romwidth 16 options to create a .rom file > with no > > boot table. Then store the .rom file in your EEPROM by parsing the > address and > > data. This will essentially create an image in your EEPROM that matches > what CCS > > would have done by downloading the .out file to SRAM. > > > > The linker should be set for run-time initialization. > > > > It's very simple, you can't miss. > > > > -Jeff > > > > > > ________________________________________________________________________ > > ________________________________________________________________________ > > > > Message: 3 > > Date: Tue, 06 Jan 2004 14:24:26 -0000 > > From: "sks_dsp" <> > > Subject: Re: problems while emulating DSK5510 with code composer > > > > Sounds like a classic pipeline latency/conflict problem. Somewhere > > you have an instruction whose result is being used before it is > > ready. When single stepping, the software TRAP that the emulator > > inserts creates enough "latency" and the result appears to be > > correct. But when running straight through the operation will be > > incorrect. > > > > Look for instructions that are known to have latency issues and add a > > few NOPs after them. Or insert NOPS here and there and retest. > > > > -Shawn > > www.appliedsignalprocessing.com > > > > > > --- In , "maxisonnaillon" <maxisonnaillon@y...> > > wrote: > > > While I emulate an example of the Image Library (quantize) I get > > > wrong results if i run the program at once, but if i run it step by > > > step, the program works right. > > > Do anyone know what could be the problem? > > > Thanx > > > Maximiliano Sonnaillon > > > > > > > > > > ________________________________________________________________________ > > ________________________________________________________________________ > > > > Message: 4 > > Date: Tue, 06 Jan 2004 14:31:35 -0000 > > From: "sks_dsp" <> > > Subject: Re: External Flash Boot > > > > We have a "loader applet" that allows dsp applications to be burned > > to the FLASH on the target hardware over a serial link: > > > > http://www.appliedsignalprocessing.com/tidsp.htm > > > > We've done this for a 5510. We normally use boot records, but I'm > > sure we could customize it for your application. Contact us. > > > > -Shawn Steenhagen > > www.appliedsignalprocessing.com > > > > > > --- In , "ajmassa" <amassa@s...> wrote: > > > > > > I have a custom board that I want to boot from external flash. I > > am > > > using a c5509. I do not want to use a boot table, I just want to > > > directly execute from flash after the DSP comes out of reset. Does > > > anyone have a (detailed) sequence of steps to do this that they > > have > > > successfully verified - from the building of the application (such > > as > > > linker options), to the conversion of the .out file, to the > > > application used to burn the flash, etc. > > > > > > Thanks. > > > > > > > > > > ________________________________________________________________________ > > ________________________________________________________________________ > > > > Message: 5 > > Date: Tue, 06 Jan 2004 16:42:33 +0200 > > From: Indrek Rebane <> > > Subject: Re: External Flash Boot > > > > ajmassa wrote: > > > I have a custom board that I want to boot from external flash. > > > I am using a c5509. I do not want to use a boot table, I just > > > want to directly execute from flash after the DSP comes out of > > > reset. > > > > Might not be so wise thing to do for sake of performance. Flash > > memory is usually quite slow (>70ns access) which will hold up > > execution of code (vs. 5ns on SARAM@200MHz, C5509A assumed). Also, > > when EMIF is used for accessing something else those other > > accesses might get slow. Extreme case being programming same flash > > chip which might get system to deadlock. > > > > Indrek > > > > -- > > Indrek Rebane | Borthwick-Pignon > > Electronics Engineer | Tartu Science Park > > Phone: (+372) 7 302 641 | Riia 185, 51014 Tartu > > Fax: (+372) 7 383 041 | Estonia > > | www.bps.co.ee

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



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