Flashing in C5505 eZdsp

The C5505 eZdsp can be flashed using a utility that runs on the target that is accessed  using Code Composer Studio v4 which comes with the board. 

The eZdsp will boot from flash when it is powered on by plugging the board into USB port on a computer.  The entire board is powered from the USB port.

Hi,

Can you describe in details that how to build the image and what tools to be used to flash the code. Thanks

Yuan,

Information on the new CCSv4 and how to use it are on our Wiki site: http://wiki.davincidsp.com/index.php/Category:Code_Composer_Studio_v4.  There is info also in the Quick Start Guide for the C5505 eZdsp which contains some info for the C5505.  I have put in request to product team on when a flash utility will be available.  I will have to come back with that information when I receive some details.

Regards.

Hi Tommy,

I have the same problem that all above. I just finish my app but I cant use it stand alone. 

 Is there any quick solution for flashing external EEPROM from eZDSP USB Stick?

I try to modify a spirom demo without success. Now read other questions in this forum I see that I need to use a hex55 to convert .out files in hex bin files before flashing EEPROM. Is it correct for eZDSP board?

tks for any help.

Regards

Fiore

from Brazil

Hello all,  

There are two steps in programing an image into the EEPROM.

1) Create an bootimage. An bootable image should be used for boot-up. The "hex55.exe" (version 4.3.3 or later) can generate an boot-image from .out file.

hex55 -i [input file name] -o [ouput file name] -boot -v5505 -b -serial8

example:

hex55 -i ..\USBKey_LED\Debug\USBKey_LED.out -o USBKey_LED.bin -boot -v5505 -b -serial8

2) Once you have an bootimage, you can program it into the SPI EEPROM by using "programmer.out". We are in the middle of releasing process of the programming tool to the public. It will be available soon. I will post the information here when it is available.

In case you need the tools urgently, please contact your local TI person (sales or FAE) and let the local TI person contact me. 

Best Regards,

Peter Chung

Are you any closer to releasing the flash program code?

Or at least the programmer.out file.

Sam

Hi Sam,

We have uploaded the EZDSP Programmer Tool to the open source site at:

http://code.google.com/p/c5505-ezdsp/

Please look for it towards the bottom of the page.

Best regards, Vishal

Thanks Vishal.

I downloaded the flash program fine but still have a problem.

I have taken the demo LED blink file ( led.out ) from the Code Composer "tests" directory and converted it to a binary as follows:

hex55 -i led.out -o led.bin -boot -v5505 -b -serial8

The output is:

"led.out"  ==> .cinit <BOOT LOAD>

"led.out"  ==> vectors <BOOT LOAD>

"led.out"  ==>.text  <BOOT LOAD>

"led.out" ==> .const.1  <BOOT LOAD>

"led.out" ==> .const.2  <BOOT LOAD>

"led.out" ==> .const.3  <BOOT LOAD>

I start Code Composer Studio and do the following:

Target -> Launch TI Debug

Target -> Connect Target

Target -> Load Program...

I then load the programmer_USBKey.out file.

I run the program and at the prompt I enter the full path of the led.bin file and press enter.

I get the following:

SPI EEPROM

Writing data to device...

Opening c:\temp\led.bin

Input file opened

... after about a minute I get "Programming Complete".

I quit Code Composer and power down the DSP stick for about 10 seconds and power it back up

however, the LED does not blink.

I have also tried this with the audio demo and it too does not work.

Have I missed something?

Vishal,

I am having the same problem with the Audio Filter program.  I have tried several times and the code does not run in the eZDSP Stick after using the procedure suggested.

Help!!

Milton Cram

Vishal,

I just noted that you said that we must use v4.3.3 or later of hex55.exe.

My version is 4.3.2.  Where do I find a later version of the utility?

Thank you,

Milton Cram

Hi Sam,

Please make sure you are using the latest version of the hex55 tool (v4.3.5). You can download hex55 with the C55x Code Generation Tools at the following link:
https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.htm#C5500

I experimented with downloading the LED test code into EEPROM with each of the four most recent hex55 releases. Here are my results:

Hex55.exe v4.3.2:        LED NOT BLINKING

Hex55.exe v4.3.3:        LED BLINKING SLOWLY

Hex55.exe v4.3.4:        LED BLINKING NORMALLY

Hex55.exe v4.3.5:        LED BLINKING NORMALLY

If problems persist, remember how the GEL file works with Code Composer – the GEL file performs fundamental initialization such as setting up the PLL and Peripherals when Code Composer connects to or resets the device.

You may need to add code to your program that performs the same tasks as the GEL file. So take a look at the GEL file for the C5505 eZdsp USBStick. The default location of the C5505 eZdsp USBStick GEL file should be:
“C:\Program Files\Texas Instruments\ccsv4\emulation\boards\usbstk5505\gel\usbstk5505.gel”

To learn more about the GEL file, see http://tiexpressdsp.com/index.php/GEL

To learn more about the bootloader, see the TMS320VC5505 Data Sheet (http://www.ti.com/lit/gpn/tms320vc5505) in section 4.4

To learn more about “hex55.exe”, see the TMS320C55x Assembly Language Tools Users Guide (http://www-s.ti.com/sc/techlit/spru280) in section 14

Hope this helps,

Mark

Hi Mark,

Running the latest version of hex55 solved my problem.

Thanksm

Milton Cram

Hello Mark,

i have a 5509A TI stand alone device and with an external SPI eeprom. i would like to boot up using this eeprom. i have downloaded the latest Code generation tools, as recommended by you. do you have a 5509A specific utility to download the .bin file into the serial eeprom.

regards

Tanman

Hi,

thanks for the helpful information here and for the bootloader tool. I tried to use it with my project and am having some trouble: The program doesn't start after power-up.

I used Hex55.exe v4.3.5. The procedure works with the 'LED' example from Spectrum Digital (the LED blinks very slow, but at least it works).

My project is based on a C5505 CSL example and therefore uses the c5505evm.gel, which does the following on target connect:

/* The OnTargetConnect() function is executed when the target is connected. */
OnTargetConnect()
{
    GEL_Reset();
    C5505_MapInit();
//    ProgramPLL_12p288MHz_clksel0();
    ProgramPLL_100MHz_clksel0();
//    ProgramPLL_120MHz_clksel0();

    GEL_TextOut("Target Connection Complete.\n");
}

I added the PLL configuration to my program (using CSL), which seems to work when loaded by CCS4, so that is not the reason why my code doesn't run when loaded from EEPROM. The only other important thing that is done by the GEL file on target connection is 'C5505_MapInit();' - but in my understanding this function sets up the memory map for the CCS4 debugger and is therefore not required for standalone operation. Is that correct?

Does anybody have any other ideas why the boot from EEPROM could fail? The size of the .bin file is around 50 KB, all peripherals are initialized and configured using C5505 CSL.

Kind regards and Merry Christmas,

Raphael

After reading the flashing/EEPROM related posts, I got under the impression that the eZdsp can get "bricked".  Is it possible that, under some conditions, the JTAG interface won't EVER be able to recover control of the device to reflash it?

Regards,

Joao

Hi,

I cannot imagine that this is possible, because the JTAG most likely puts the CPU in a reset condition during load. Maybe James Huang, who reported an issue similar to the problem you describe, can give some feedback on how he solved it finally.

I would also be interested if the flashing how it was described by Mark works with different code examples. I still cannot get my code running properly from the EEPROM. It does something, meaning that I can hear a very noisy audio signal which I bypass over DMA from the codec to the codec without processing, but everything else doesn't seem to work (UART, LED blink, audio processing of other channels).

Same with the AudioFilter example: It runs somehow, but not as it does when loaded from CCS4. The Audio signal is very noisy/corrupted.

I would be very glad to receive some help on this issue by one of the TI employees or somebody else who managed to flash his usbstick successfully... @Milton Cram, did your AudioFilter behave exactly as it is supposed when running from flash?

Best regards,

Raphael

I did end up "bricking" 2 of these boards in my efforts in flashing to eeprom. For the first one I just physically lifted (disconnected) the power pin to the EEPROM so that i would be able to connect to the device using CCS4

Somehow, I managed to get the second one connected after screwing it up by fumbling with some settings of CCS4, I cannot recall exactly what I did, but I believe it had something to do with not loading something upon connection to the USB port. Once of got it to connect I reloaded the default program back onto it using the programmer tool to bring it back to its previous state.

What I did was I looked in the code of the default loaded program (blinking LED plus pitches of alternating frequency). I don't recall where this is located online, but in the main() of the code, there are two functions InitSystem() and ConfigPort() which are called in the beginning of the main(). These two functions are also defined in same file. I copied these two function definitions into my code and called them in the beginning of my main, then flashing the EEPROM worked as expected with the method described in the first page.

Hope this helps.

In another thread, Ming Wei (TI employee) said:

"I think the problem may cause by the pre-flashed program in the EEPROM... There are two possibilities, either the bootable image in the EEPROM is faulty, or the execution of the program in EEPROM prevents the JTAG to load your example code into RAM."

I will hold on to buying these kits until I get a confirmation from TI that is always possible to recover the device from a bad EEPROM image.

Regards,

Joao

Hi James,

thanks for your explanations. Did you try the AudioFilter example as well? I guess the latter uses the same init routines, and as it doesn't work with my configuration I am afraid that copying the init routines won't solve my problem...

I cannot find the source code for the default loaded program anywhere. I assume it is only installed when installing CCSv4 from the Spectrum Digital DVD, I downloaded the latest version from TI and there are no examples included. Is there some other source for the default program code? Or could anybody please attach it to a post within this forum?

Kind regards and many thanks,

Raphael

Edit: I have the code now and copied the functionality of the 2 init routines, but my program still doesnt behave as it should :(

James Huang said:

I did end up "bricking" 2 of these boards in my efforts in flashing to eeprom. For the first one I just physically lifted (disconnected) the power pin to the EEPROM so that i would be able to connect to the device using CCS4

Somehow, I managed to get the second one connected after screwing it up by fumbling with some settings of CCS4, I cannot recall exactly what I did, but I believe it had something to do with not loading something upon connection to the USB port. Once of got it to connect I reloaded the default program back onto it using the programmer tool to bring it back to its previous state.

What I did was I looked in the code of the default loaded program (blinking LED plus pitches of alternating frequency). I don't recall where this is located online, but in the main() of the code, there are two functions InitSystem() and ConfigPort() which are called in the beginning of the main(). These two functions are also defined in same file. I copied these two function definitions into my code and called them in the beginning of my main, then flashing the EEPROM worked as expected with the method described in the first page.

Hope this helps.

Hi James,

I just encountered exactly the same behaviour,  "bricked" device due to a "faulty" program in EEPROM. Actually I did something wrong with the DMA initialization, and therefore the program got stuck in a CSL subroutine, but that resulted in the impossibility to connect to the target. Rememering your post, I also played around with some settings and were successful. For the future and anybody else having the same issue, what you have to do when target connection is no more possible due to a "catastrophic" memory something:

- Menu "Tools/Generic Debugger Options"

- Unselect "Remove remaining debug state at connect"

This allowed me to connect to the target as before.

Regards,

Raphael

Raphael said:

 

Hi,

thanks for the helpful information here and for the bootloader tool. I tried to use it with my project and am having some trouble: The program doesn't start after power-up.

I used Hex55.exe v4.3.5. The procedure works with the 'LED' example from Spectrum Digital (the LED blinks very slow, but at least it works).

My project is based on a C5505 CSL example and therefore uses the c5505evm.gel, which does the following on target connect:

/* The OnTargetConnect() function is executed when the target is connected. */
OnTargetConnect()
{
    GEL_Reset();
    C5505_MapInit();
//    ProgramPLL_12p288MHz_clksel0();
    ProgramPLL_100MHz_clksel0();
//    ProgramPLL_120MHz_clksel0();

    GEL_TextOut("Target Connection Complete.\n");
}

I added the PLL configuration to my program (using CSL), which seems to work when loaded by CCS4, so that is not the reason why my code doesn't run when loaded from EEPROM. The only other important thing that is done by the GEL file on target connection is 'C5505_MapInit();' - but in my understanding this function sets up the memory map for the CCS4 debugger and is therefore not required for standalone operation. Is that correct?

Does anybody have any other ideas why the boot from EEPROM could fail? The size of the .bin file is around 50 KB, all peripherals are initialized and configured using C5505 CSL.

Kind regards and Merry Christmas,

Raphael

I finally solved the issue, the problem was that the DMA was on idle due to the bootloader. Solution is described here:

http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/110/p/33709/117751.aspx#117751

Regards,

Raphael

Hi Raphael,

I am trying to boot from EEPROM for the first time. I am trying with the "led" example given in tests. I saw the usbstk5505.gel file and from that I added the following to the main.c of "led" example. I called the ProgramPLL_100MHz() function just after entering main.

#define PCGCR1   0x1c02
#define PCGCR2   0x1c03
#define CCR2     0x1c1f
#define CGCR1    0x1c20
#define CGCR2    0x1c21
#define CGCR3    0x1c22
#define CGCR4    0x1c23

void ProgramPLL_100MHz(void){

int i;

    printf("Configuring PLL (100.00 MHz).\n");
    /* Enable clocks to all peripherals */
    *(short *)PCGCR1@IO = 0x0;
    *(short *)PCGCR2@IO = 0x0;

    /* Bypass PLL */
    *(short *)CCR2@IO = 0x0;

    /* Set CLR_CNTL = 0 */
    *(short *)CGCR1@IO = *(short *)CGCR1@IO & 0x7FFF;

    *(short *)CGCR2@IO = 0x8000;
    *(short *)CGCR4@IO = 0x0000;
    *(short *)CGCR3@IO = 0x0806;
    *(short *)CGCR1@IO = 0x82fa;

    /* Wait for PLL lock */
    for(i=0;i<0x7fff;i++);

    /* Switch to PLL clk */
    *(short *)CCR2@IO = 0x1;

    printf("PLL Init Done.");

}

As expected, I have compilation error for all the @IO . Will the PLL init be properly done if I just remove all @IO? What else do I need to add to my main.c for proper initialization of the USB stick?

After compiling, I understand that I have to create led.bin from led.out using hex55 utility, load the led.bin using the programmer.out program. Then the "led" program should run just after power up without ccsv4. Am I correct in my understanding?

Thanks in advance,

Riju

Hi, I have flashed the led and aic3204 porograms succesfully and they run without ccsv4. I will now try the audio filter and will get back if any issue arises.

Thanks,

Riju

Hi,

I can no longer connect to the board and I get this error message :

Error connecting to the target:
Error 0x80000242/-1143
Fatal Error during: Memory, Initialization, OCS,
The memory at 0x000000BE continually indicated it was 'not ready'
All memory operations currently in progress were aborted in order
to regain control of the processor.
This is considered a catastrophic event, but the debugger should
still be able to access memory and CPU registers.
System state has been altered.  It is strongly advised
that the processor should be reset before resuming execution,

The problem appeared after connecting a potentiometer between the 1V3 Test point, the ground and GPAIN 3.

I tried Raphael's solution but I still get the error message.

I also tried to short the clock line and the "data-in" line when inserting the eZDSP into the USB slot but the error message is still her...

Does that disconnect the EEPROM will be a solution, even if the other tips didn't works ?

What can I try ?

Thanks in advance,

Thierry.

Hi Thierry,

That 1V3 Test Point is tied to the DSP's core supply voltage. The potentiometer may be disrupting the core voltage, preventing the device from connecting.

What voltage reading are you seeing with and without the potentiometer attached? Does the device connect if the potentiometer is removed?

If you are experiencing a corrupt boot image in the SPI EEPROM, and none of the previously documented solutions work you might try the following (not tested):

The bootloader attempts to boot from each external memory a fixed order: NOR, NAND, SPI EEPROM, I2C EEPROM, MMC/SD, then UART/USB

You have about 100 ms before the bootloader attempts to boot from the SPI EEPROM. You could try to power on and connect to the target before the SPI EEPROM begins to boot. Its a very tight game of timing, but it may work.

Once you have connected, if the EEPROM was the culprit, rewrite the contents of the EEPROM with either a good boot image or just overwrite the valid boot signature (0x09AA) from the first two bytes of the EEPROM. This will prevent the bootloader from booting the bad image.

Let us know if you get it to work. This kind of debugging process would make a great wiki entry.

Hope this helps,
Mark

Hi,

Thank you for replying,

The problem exists if the potentiometer is attached or not, and the voltage is always at 1V3.

I don't know if I understand well, but I doubt your solution works because the bootloader starts as I plug the device in the USB port and windows recognize it one or two seconds later, and maybe the boot is already loaded when windows allow me to connect the device.

I tried it several time and I never succeded to connect the eZDSP.

Thanks for your help,

Thierry.

edit : I have 3 different messages :

C55xx: Error connecting to the target: Error 0x80000242/-1143 Fatal Error during: Memory, Initialization, OCS,  The memory at 0x000000BE continually indicated it was 'not ready' All memory operations currently in progress were aborted in order to regain control of the processor. This is considered a catastrophic event, but the debugger should  still be able to access memory and CPU registers. System state has been altered.  It is strongly advised that the processor should be reset before resuming execution, 
C55xx: Error connecting to the target: Error 0x80003240/-121 Fatal Error during: Initialization, OCS, Target, Control, 
C55xx: Error connecting to the target: Error 0x80002240/-121 Fatal Error during: Initialization, OCS, Control,

Hello,

I'm trying to program an image into EEPROM for the C5515 eZdsp kit, but assume the procedure should be the same as discussed here for the C5505.

I generated the .bin file, and then loaded programmer_USBKey.out into CCSV4, and ran.  At the prompt, I entered the .bin file created from my project .out file, and hit enter.  At that point it gave me the following error

    Input file opened
    WRITE ERROR! at 0x0000
    Wrote 0x0002 Read 0x0000

Can someone help me understand why this might be?

Thanks,

Robert

P.S.  I'm able to run my program successfully when using  CCS4.

Hello Robert,

The C5515 eZdsp contains a NOR Flash instead of an EEPROM.

To burn the NOR flash on the C5515 eZdsp use the nor_writer program available on Spectrum Digital's C55515 eZdsp Support site (http://support.spectrumdigital.com/boards/usbstk5515/reva/).

Donwload the "Test Code" zip file from that website. Then browse to "usbstk5515_BSL_RevA.zip\usbstk5515_v1\tests\nor_writer\"

Hope this helps,
Mark

Hello Mark,

We had a class project that we based off on the FFT example for C5505. It has been bugging me for a while that we couldn't get the flash version working.

We had a real-time (almost) sound application running but outside the CCS-GEL connection, sound output comes distorted and very slow. We understood how to write programs via hex55 and the Programming tool that's posted, but writing GEL into C has been confusing. Blink LED worked on flash, but when the actual sound comes to play, it hasn't been successful.

Is there any document or forum thread that clearly explains the whole process?

Thank you

Hi Anand, please, give me more details about how corrupt the data lines of the NOR-Flash chip at the boot time, I am having the same problem (bellow).

C55xx: Error connecting to the target: Error 0x80000242/-1143 Fatal Error during: Memory, Initialization, OCS, The memory at 0x000000BE continually indicated i

t was 'not ready' All memory operations currently in progress were aborted in or der to regain control of the processor. This is considered a catastrophic event,

but the debugger should still be able to access memory and CPU registers. System state has been altered. It is strongly advised that the processor should be

reset before resuming execution.

Thanks,

Andrea

Hi Andrea,

This will work only if you have corrupted  the NOR flash with a faulty boot code, say wrong PLL setting or so.

In theory, shorting two data lines at boot time with a Oscilloscope probe or a small piece of wire will corrupt the boot signature 0x09AA, which is the first word in a boot image.

Now in my case,  I just checked the schematics and looked at the data lines for the NOR flash chip and shorted pins 29(data D0) and 30(data D8). 

All the best.

Hello All,

I have a related question - I tried to FLASH a program onto a eZdsp 'c5515 board - and the program just ran and never terminated normally.

I haven't had time to look at what could be wrong - is there a size limitation?  I believe my current code size is something like 26K or so - which
isn't big but the programmer just hangs.

Thanks,
johnw

Mark,

This file was updated on 8/04/10 - just downloaded it - I will see if that fixes my issue.

Regards,
johnw

Hi Anand, how are you?

I still having problem when flash the NOR-flash of my C5515 eZdsp. I did what you recommended and my memory works again, thanks.

Now, I would like to know if you have success flashing other codes (not the example supplied by Spectrum Digital) in NOR-flash of your C5515 eZdsp?  It is because I tried many times but always I corrupted the memory.

Please, could you give me a help? For example, what will you do (step by step) to flash the example “usb” (supplied by Spectrum Digital) in the NOR-flash.

Many, many thanks,

Andrea

Hi Andrea,

The main thing you need to consider while flashing the NOR is the PLL ssettings.

Check the source code of the example program that comes with the ezDSP. I contains the PLL settings embedded in the C code itself.

In any other case it will be done only on the GEL file. But that will not be included in the executable code generated by CCS.

Now after includng the PLL settings in your code and generated a .out file, you can follow these steps 

1 . download the latest flash writer code from : http://support.spectrumdigital.com/boards/usbstk5515/reva/files/usbstk1151_Demo_RevA.zip, extract that to a folder

2.  copy your .out file to the /source/hex_utility/ directory in the usbstk5515_demo folder and edit the demo.cmd file with a text editor.

3.  change the file name in the last two lines to your file name, shown in red color

-boot

-v5505

-serial8

-b

-o .\EZDSP_Sample.bin

.\EZDSP_Sample.out

4. Open a command prompt from start->accessories and navigate to the \USBSTK5515_demo\source\hex_utility\

5. type hex55 demo.cmd at the command line, a .bin file with the file name you provided will be generated

6. This you can use with the NOR_writer.out for flashing and it will work fine

PN: The PLL settings initialization can be referred from InitSystem function in the main.C in the  USBSTK5515_demo\source\USB_Stick_Sample\source directory

To use the USB example you have to consider PLL settings for USB as well. I am yet to work on that.(I'll try to update it here once done)

All the best.

I was having the same memory problem with the C5515 ezDSP.  I was having a terrible time finding it, because even after I took out the PLL configuration (the likely culprit) it was still happening.

I then noticed in the datasheet that the bootloader uses block SARAM31 for its operations (byte addresses 0x04e000 through 0x050000).  Guess where I had located .cinit!  I changed my .cmd file and the problem went away.  I am a little surprised this was able to disable the JTAG interface, but there it is.

Regards,

Bill 

Hi Bill,

Really appriciated.

This is real problem solving.

reagards

Anand CV

Hi Bill,

I am having problem when try flash programs in my C5515 eZDSP. I posted a doubt http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/t/59233.aspx but nobody answered me.

According your post, the problem is the localization of .cinit, but in my case .cinit was in other place and did not work according detail on the link above.

Do you can flash the examples supplied by Texas on C5515 eZDSP? I am ok with the procedure to record flash, I did it a couple of times changing the EZDSP_Sample . But when I try flashing other example I always corrupt the memory. Please, could you give me step by step what do? For example, to flash the example CSL_MMCSD_SdCardFSExtExample_Out on C5515 eZDSP?

Sorry, I know that seems to abuse, but I have exhausted my ideas to solve this problem.

Any help would be very welcome.

Regards,

Andrea

Hi Andrea,

Since you have been able to flash the EZDSP_Sample, maybe you can just use that same project, but change the .c file(s) to the different ones you want.  So 1) back up EZDSP_Sample project 2) remove the .c files from it 3) add the new .c files you want 4) rebuild the project, including creating the new .bin ouput file and 5) flash it.  Do not change anything else, other than the .c files.

Regards,

Robert

Andrea,

Can you clarify what you mean when you say that the 'memory is corrupted'? Are you not able to write the code to the NOR flash or is it that it doesn't work stand alone once it's been written?

Regards,

Mugdha 

Hi Mugdha!

In my case 'memory corrupted' means: 1) It doesn't work stand alone once it's been written; 2) I am not able to write code to the NOR flash because CCS stops to connect to target.

Thanks for any help.

Andrea

Hi Andrea,

Did you check the post I have posted long back?

http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/110/p/11099/225355.aspx#225355

And a still better solution by Robert

http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/110/p/11099/275324.aspx#275324

Hi Andrea,

Please take a look at the process of burning the NOR flash given in our FAQ #4 and #5 on C5000 Wiki page. If you follow this process you should be able to burn any program in the NOR flash successfully. If the program does not work stand alone after following this procedure, then it would point towards something else missing in the code itself.

Thanks,

Mugdha 

Hello,

I am trying to program the C5505 eZdsp to work in stand alone mode.

The size of the .bin file of the program is around 110KB. So I cannot boot this off the EEPROM. What can be done to boot the program from the usb stick?

Can

a) Some external memory device be attached to boot the program off it?

b) the same program work with C5515 eZdsp (which has a 4MB NOR Flash) with no/minimal changes?

Thanks and Regards,

Ramesh