C5515 ezdsp - can't run from RAM, after bad image flashed

Robert Wolfe

Other Parts Discussed in Thread: TMS320C5515

Hello,

I made a change to my program for the C5515 ezdsp, and flashed it in using norwriter. But it has caused some problem, and I can now connect to the target via CCS, but cannot load and run a new program into RAM. It says it's loading and running it, but it is really running the last program that I had flashed in. And I can't update the flash to get rid of that previously flashed, problem image ... because it won't run norwriter again.

Help please.

Robert

over 13 years ago

0 Peter Chung over 13 years ago

TI__Expert 8065 points

Robert,

After connecting it to CCS, load a different program whihc is known to be good and run it first. And then, try to load the norwriter.

Regards,

Peter Chung

0 Robert Wolfe over 13 years ago in reply to Peter Chung

Mastermind 7860 points

Peter,

Thanks for the reply. But no matter what I load, even a different, known good program first, it still is always executing the bad program I had flashed in previously using norwriter. So today, after your suggestion, I had 1) loaded the different, known good program and ran - result: still running bad one and then 2) loaded norwriter and ran - result: still running bad one.

I can tell it's the bad one by it's distinct led flash rate.

Regards,

Robert

0 Mark Mckeown over 13 years ago in reply to Robert Wolfe

TI__Mastermind 29270 points

Robert,

When you connect, are you able to read/write to memory through CCS?

I'd like you to try to disable all clock gates in the PCGCR1 and PCGCR2 registers except SYSCLK and ANAREG and see if you can then load your program.

Refer to 1.5.3.2.1 Peripheral Clock Gating Configuration Registers of the C5515 System User's Guide (http://focus.ti.com/lit/ug/sprufx5/sprufx5.pdf#page=39).

In the IO memory, set 0x1C02 to 0x7FFF and set 0x1C03 to 0x003F to clock gate all peripherals except analog. Then see what happens when you load your program.

If it works, load nor_writer and remove the program that is in there.You can just overwrite the boot signature: When the first two bytes in NOR equal 0x09AA the bootloader begins copying that boot image into memory. If those bytes are cleared, the bootloader will skip that boot image.

When you use hex55, which Code Gen Tools version are you using? With CGT 4.3.6, the -v5515 version does not work. Here are the flags that I use:

hex55_v436 -boot -v5505 -serial8 -b COFF.out -o BINARY.bin

Refer to the Bootloader App Note (http://focus.ti.com/lit/an/sprabd7/sprabd7.pdf#page=6)

I've got some more ideas if this one does not work.

Hope this helps,
Mark

0 Robert Wolfe over 13 years ago in reply to Mark Mckeown

Mastermind 7860 points

Mark,

I was able to write to memory, and wrote the suggested values for 0x1c02 and 0x1c03. My memory window looked the same for those 2 locations, as the one you attached. After that, I loaded norwriter, and hit run. At that point, it was still running the bad program (with no usual norwriter prompt for the binary file location, etc).

Can you explain a bit more about overwriting the boot signature, and 0x09AA? I assume that was only relevant if the first part was successful. But I also use CGT 4.3.6, and same flags, to successfully create the boot image. When writing that to norflash, using norwriter, does it write in 0x09AA to the first 2 bytes (so the boot image will be copied into memory)?

Ready to try your other ideas....

Thanks,

Robert

0 Omkar over 13 years ago in reply to Robert Wolfe

Prodigy 140 points

Robert,

What the disassembly is showing when you load a new program. You can debug it by step-in instead of running the program, after loading a new program. Have you already tried it?

Regards,

Omkar

0 Robert Wolfe over 13 years ago in reply to Omkar

Mastermind 7860 points

Yes, I have. Have you tried debugging disassembly lately, without the source file? Not easy...

It begins in vectors/boot, with calls to unknown functions, branches, etc. Almost impossible without some frame of reference or source code. It's be easier if I had the correct boot.asm. The map file said it comes from rts55x.lib. But when looking at the source associated with that library in the TI tools directory (rtssrc.zip), the boot.asm instructions don't match what my program is doing.

After hitting run, and then stopping, I can roughly see the disassembly is associated with the LED while loop from my bad program.

Regards,

Robert

0 Robert Wolfe over 13 years ago in reply to Mark Mckeown

Mastermind 7860 points

Mark,

Were you going to share your other ideas?

Robert

0 D E Ungar over 13 years ago

Intellectual 680 points

Two things of importance about the nor_writer.out application provided by Spectrum Digital :

Of all the sample code Spectrum Digital and T.I. provide with the C5515 ezDSP and in downloads usbstk1151_Demo_RevA.zip and usbstk5515_BSL_RevA.zip (and of all the examples in T.I.'s Chip Support Library in TMS320VC55XCSL-LOWPWR-2.01.00.00.zip), to the best of my knowledge only USB_Stick_Sample [project EZDSP_Sample] performs all requisite clock generator configuration and clock domain gating. [Some of EZDSP_Sample initialization code is contained in USB_Stick_Sample\asm\vector.asm - which entails an altered entry point in the project configuration.] All the other examples assume that you have already booted into a program that has done this initialization before downloading the other example code via the emulator.

So, you may have to load EZDSP_Sample.out via the debugger and run it to initialize the C5515 completely before loading and running nor_writer.out.:
Target->Start TI Debugger
Target->Connect Target
then, first for EZDSP_Sample.out, then for nor_writer.out:
Target->Load Program
Target->Run
Target->Halt
nor_writer.out, as supplied, will only program up to 16 KB of Flash memory; any larger .bin file will result in a unprotected buffer overrun that will eventually step on nor_writer's own code. I had to hack the program to do iterative file reads and Flash writes to handle larger files - see my snarky comments at http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/p/52076/254009.aspx#254009.

Dan

0 Robert Wolfe over 13 years ago in reply to D E Ungar

Mastermind 7860 points

Dan,

Thanks for the reply. I tried 1. above (use EZDSP_Sample.out before nor_writer.out), but again to no avail. I saw your informative comments in that other thread, as I had started that one as well, and continue to get updates ;)

I started with their USB_Stick_Sample as the basis for my application. And all was well, until I made some deadly modifications to the I2C initialization.

So now I'm still left with a useless, frozen EZ DSP kit (well, not so easy so far). Although it does have nice blinking LED to it.

Regards,

Robert

0 D E Ungar over 13 years ago in reply to Robert Wolfe

Intellectual 680 points

That does sound disheartening.

One other thing you might try that I read in this forum at
http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/110/t/11099.aspx?PageIndex=2
as posted by Raphael:

- Menu "Tools/Generic Debugger Options"

- Unselect "Remove remaining debug state at connect"

This allowed me to connect to the target as before.

Actually, you need to have the debugger running and select Tools -> Debugger Options -> Generic Debugger Options

From CCSv4 help:

Remove remaining debug state at connect:
In some cases, CCS is not able to remove all breakpoints when disconnecting. Enabling this option causes CCS to reattempt to remove any software breakpoint opcodes from memory at connect. This reattempt causes the IDE to access memory (and could potentially put targets in a bad state if that memory is no longer valid). If a target connect is failing due to a silicon bug, disabling this option may let you connect to the target more reliably. This option is enabled by default.

Sounds to me like the debugger may attempt to unpatch software breakpoints that, of course, don't exist if you've just booted from code in Flash memory, thereby restoring swapped-out code into a completely unrelated program. Unchecking this box would prevent that.

Sometimes the only way I've gotten this pup to work is to completely shut down CCSv4 and unplug the ezDSP, then start fresh.

Best of luck,

Dan

0 D E Ungar over 13 years ago in reply to D E Ungar

Intellectual 680 points

Just another wild thought:

My original version of usbstk5515.gel as received with CCSv4 has OnPreFileLoaded() and OnFileLoaded() both defined as null:

OnPreFileLoaded()
{
/* Reset the CPU to clean up state */
//GEL_Reset();
}

// ...

OnFileLoaded()
{
}

Make sure your version of usbstk5515.gel didn't somehow get altered to do a GEL_Reset() in OnFileLoaded() - that would invoke the boot loader and wipe out whatever you just downloaded.

Under View -> Target Configurations, make sure you haven't created a custom .ccxml that links to a non-standard .gel file. (For example, I have a crippled .gel file in which I've commented out everything in OnTargetConnect() to allow me to break into the program running from Flash boot-load without disturbing anything - I commented out GEL_Reset(); Peripheral_Reset(); ProgramPLL_100MHz(); )

Dan

0 Mark Mckeown over 13 years ago in reply to D E Ungar

TI__Mastermind 29270 points

Thanks Dan,

These are ideas that I would also recommend.

If these fail, you (Robert) could also try to manually erase the first two bytes of the NOR flash (the boot signature) by writing to the same registers/mem addresses as the nor_writer code (Using the memory window of CCS).

I have not actually tried this, but I'll give it a shot if these other ideas fail. Sorry for the delay - I've been out of the office.

Best Regards,
Mark

0 Robert Wolfe over 13 years ago in reply to D E Ungar

Mastermind 7860 points

Dan,

I unchecked "Remove remaining debug state at connect", and confirmed that Target Configuration is linked to the original usbstk5515.gel, which has the GEL_Reset() commented out likes yours (plus shutdown CCSV4 and unplugged the ezDSP). I'm still at the same impasse, but appreciate the additional suggestions.

Thanks,

Robert

0 Robert Wolfe over 13 years ago in reply to Mark Mckeown

Mastermind 7860 points

Mark,

From what I could see of the nor_writer code, it starts at FLASH_BASE of 0x400000 (so assume 0x400000 and 0x400001 are the boot signature). When bringing that location up in a CCS Program window, I'm not allowed to change those 2 bytes. I can enter 0 for them, but it doesn't change their existing value (0x10 as first byte and 0xAC as second).

Thanks,

Robert

0 D E Ungar over 13 years ago in reply to Robert Wolfe

Intellectual 680 points

Robert,

Writing to Flash memory requires writing certain code words to certain addresses in the Flash memory before writing the actual data word to the targeted address, then repeatedly checking what you have written until the sequencer within the Flash memory has completed the process.

From norflash.c, with my additional comments to the right:
        /* Program one 16-bit word */
        FLASH_CTL555 = FLASH_CMD_AA;           // Write three code words to activate the Flash memory write sequencer
        FLASH_CTL2AA = FLASH_CMD_55;
        FLASH_CTL555 = FLASH_PROGRAM;
        *pdst16 = *psrc16;                     // Copy one word from RAM to the target address in Flash memory

         /* Wait for programming to complete */
        // Wait for operation to complete      // This will probably be faster than you can see with the debugger; just refresh the Memory view to check
        while(1)
            if (*pdst16 == *psrc16)
                break;
See norflash.h for definitions of the above address and data constants.

Normally, if you wanted to write a specific value into Flash memory, you would first have to erase the segment of Flash memory containing it, but I think that erasing returns the Flash memory contents to all ones and by programming it you are selectively overwriting zeros, so you could simply overwrite the boot signature of 0x09AA (at address 0x400000) with 0x0000 to inhibit the boot loader from loading your code from Flash.

Hmm, I notice that you said that the first two bytes you see at 0x400000 are 0x10 and 0xAC. This is not the boot signature (which is 0x09AA). Make sure that in the Memory view of the debugger, you are looking at 0x400000 in DATA space (not program or I/O).

Dan

0 Robert Wolfe over 13 years ago in reply to D E Ungar

Mastermind 7860 points

Dan,

You're right ... data space ;) And 0x09aa is located at address 0x400000.

I manually tried to overwrite that with 0x0000, following the procedure you've indicated (and per norflash.c), but wasn't successful. I wasn't able to update any word nearby either (like address 0x400010).

Here's what I did:

1) open 3 data memory windows : 0x400000, 0x400555, 0x4002aa ... the latter 2 being the FLASH_CTL555 and FLASH_CTL2AA addresses.

2) write 0xaa to 0x400555 (the FLASH_CMD_AA value)

3) write 0x55 to 0x4002aa (the FLASH_CMD_55 value)

4) write 0xa0 to 0x400555 (the FLASH_PROGRAM value)

5) try to write 0x0000 to address 0x400000 (or some nearby address)

6) hit refresh on the memory window a few times.

No change occurred during multiple attempts. Maybe there's some write timeout that can't be met when doing it manually.

Thanks,

Robert

0 D E Ungar over 13 years ago in reply to Robert Wolfe

Intellectual 680 points

Robert wrote

> Maybe there's some write timeout that can't be met when doing it manually.

Yeah, I was afraid that might be the case. Perhaps you could poke some code into RAM and run it via the debugger.

When I load my nor_writer.out, here is the code from norflash.c:norflash_write() that actually does the programming (as seen in Disassembly view, plus my annotation to the right):

          C$DW$L$_norflash_write$2$B, C$L15:
0x02362B:   fb3100aa400555           MOV #170,*(#0400555h) ; FLASH_CTL555 = FLASH_CMD_AA;
0x023632:   e631554002aa             MOV #85,*(#04002aah)   ; FLASH_CTL2AA = FLASH_CMD_55;
0x023638:   fb3100a0400555           MOV #160,*(#0400555h) ; FLASH_CTL555 = FLASH_PROGRAM;
0x02363F:   ed10bf                   MOV dbl(@#08h),XAR3    ; XAR3 = psrc16;
0x023642:   ed14af                   MOV dbl(@#0ah),XAR2    ; XAR2 = pdst16;
0x023645:   806104                   MOV *AR3,*AR2          ; *pdst16 = *psrc16;

In Memory view (PROGRAM space), this shows as
C$DW$L$_norflash_write$2$B, C$L15
FB 31 00 AA 40 05 55 E6 31 55 40 02 AA FB 31 00 A0 40 05 55 ED 10 BF ED 14 AF 80 61 04

I think you might be able to execute the code manually by doing the following:

In Memory view, PROGRAM space (which uses byte addresses), insert the following opcodes somewhere in RAM

fb3100aa400555           MOV #170,*(#0400555h) ; FLASH_CTL555 = FLASH_CMD_AA;
e631554002aa           MOV #85, *(#04002aah)  ; FLASH_CTL2AA = FLASH_CMD_55;
fb3100a0400555           MOV #160,*(#0400555h) ; FLASH_CTL555 = FLASH_PROGRAM;
fb310000400000           MOV #0, *(#0400000h) ; FLASH_BASE   = 0x0000;

followed by a dummy instruction.
In Disassembly view (which uses byte addresses), set a breakpoint at the dummy instruction (and check that the disassembly matches the above code).
In Register view, Core Registers, set PC to the byte address of the start of the above code in your memory.
Hit run.
Wait for the breakpoint to be reached.
In Memory view, DATA space (which uses word addresses), examine 0x400000; refresh if needed.

[ C55x v3.x CPU Mnemonic Instruction Set Reference Guide (SWPU067E)
p 471: MOV        Load Memory with Immediate Value
    Opcode K8 1110 0110 AAAA AAAI KKKK KKKK
           K16 1111 1011 AAAA AAAI KKKK KKKK KKKK KKKK
p 779: Smem addressing mode:
                         AAAA AAA1             Smem indirect memory access:
                         0011 0001             *(#k23)
p 785:                              KKK . . . K Signed constant of n bits

I have no clue as to why the compiler compiled the second operation above as an 8-bit operation; both destinations are defined in norflash.h as *( volatile Uint16* ) and all three commands are defined as 2-digit hexadecimal values; the only difference I see is the number of decimal digits, which shouldn't matter. ]

A couple of things to investigate that might give you some clues as to why nor_writer.out doesn't run when you download it:

When you download nor_writer.out into your ezDSP, does the PC the point at _c_int00 (as seen in the Disassembly view)?
If you enter "main" in the "Enter location here" box of the Disassembly view and hit enter, do you see the main() code for nor_writer.out or for your damaged application?
If, in Disassembly view, you enter the of name a function that exists in nor_writer.out, but doesn't exist in your application, does it appear in the Disassembly view and does it appear to be the right code?

Dan

0 D E Ungar over 13 years ago in reply to D E Ungar

Intellectual 680 points

By the way, while I was experimenting with setting the PC to point to C$DW$L$_norflash_write$2$B, C$L15, I must have accidentally executed some code, because all of a sudden my reference ezDSP (previously un-tampered) would no longer boot the demo program from Flash. Examining the Flash memory I found that I'd somehow corrupted the boot signature and cleared every 4th byte in Flash. Fortunately, I was able to restore the original factory contents from an image I'd read out and saved. (The original Flash image differs a bit from the .bin and .out downloaded from Spectrum Digital and that came with the ezDSP installation disk.)

Dan

0 Mark Mckeown over 13 years ago in reply to D E Ungar

TI__Mastermind 29270 points

Dan,

Sounds promising for Robert if you were able to corrupt the boot signature. That should fix his booting problem.

Perhaps we can put a routine in the GEL file that clears the boot signature bytes of the NOR flash.

Thanks,
Mark

0 Robert Wolfe over 13 years ago in reply to D E Ungar

Mastermind 7860 points

Dan,

I wasn't able to get to all your suggestions and questions, but plan to do so. However, I went right to also setting my PC to C$DW$L$_norflash_write$2$B. Interesting enough, it took me to the red line below (FLASH_CTL555 = FLASH_CMD_AA);, from the norflash.c. Seeing as how I was at the section of code that was going to do the flash write, I just modified the pdst16 and psrc16 pointers, to 0x400000 and 0x8000 respectively. And at 0x8000 I wrote 0, and hit go and broke where the pointers are incremented at the bottom of the loop. More comments below ...

for ( i = 0 ; i < length ; i += 2 )

{

/* Program one 16-bit word */

FLASH_CTL555 = FLASH_CMD_AA;

FLASH_CTL2AA = FLASH_CMD_55;

FLASH_CTL555 = FLASH_PROGRAM;

*pdst16 = *psrc16;

/* Wait for programming to complete */

// Wait for operation to complete

while(1)

if (*pdst16 == *psrc16)

break;

pdst16++;

psrc16++;

}

It seems to have over-written the boot signature with a 0. I wasn't able to do the same with 0x4000001, or 4000002 and things got a little weird when trying (sort of like your corruption) with similiar, repeated patterns being written to all of the flash. In one case 0xad0b 0x0000 repeated, and the second time 0x9aa5 0x9ae5 repeated.

But I figured since the boot signature was over-written, to try and load and run norwriter. I didn't have successful norwriter program sequence, though, with asking for the location of the bin, etc. When first loading norwriter.out, the PC is at location 0xff6adc ( I have "Run to main on program load or restart" unchecked). And then after hitting run, and break, it ends up at 0xffd05b pretty much everytime. Once doing this, 0x400000 is back to 0 in the memory window, and the rest of flash from there is changing values in a more typical manner, and not the repeated sequences mentioned before.

Not sure if there are anymore clues from this, but at least there's a change ;) And interesting that norwriter seems to be resident, allowing me to takes these steps to begin with.

Thanks,

Robert

0 Robert Wolfe over 13 years ago in reply to Robert Wolfe

Mastermind 7860 points

correction to last post "I wasn't able to do the same with 0x400001 or 0x400002"

0 D E Ungar over 13 years ago in reply to Robert Wolfe

Intellectual 680 points

Robert,

Sounds like you've made some progress.

> When first loading norwriter.out, the PC is at location 0xff6adc

I initially wrote this from home (which is why I was momentarily in sync with your time zone), but I'm pretty sure that 0xff6adc is the entry point of the boot loader in permanent on-chip ROM. Whenever I load a program via the debugger, depending on whether I have the debugger option for "Run to main on a program load or restart" enabled, immediately after loading the PC will always either be at _c_int00, (or whatever the entry point is at the top of the .map file) or main. Somehow, when you load on your system, the debugger must be executing a GEL_reset() or something equivalent that is returning the PC to the hard-reset starting point in the boot loader. Since you no longer have a valid boot signature, the boot loader will not do anything useful and probably finish up in a tight loop.

I would suggest you start the debugger and connect to target. This should leave your PC somewhere in an endless loop in the boot loader, I think - this is probably the location 0xffd05b you experience.
Next, download nor_writer.out and see where doing so leaves your PC.
If it's at the boot loader again, I would look up the entry point in nor_writer.map (probably at _c_int00), poke its byte address or its symbolic name into the PC and run.

Now, the one last potential gotcha is that since you don't load a program with full clock generator and clock gating initialization from Flash before you download nor_writer.out, clocking to the EMIF may be disabled so you won't be able to access the Flash chip. However, now that I think about it, I completely powered down my ezDSP and restarted with a corrupted boot signature and was able to run nor_writer OK, so I think that after reading from Flash, the boot loader must have left the EMIF clock enabled. (If you haven't powered down the ezDSP, things will probably be correctly configured. At worst, you would have to graft the requisite initialization code [which you said you already know about and used in your own code] onto the beginning of nor_writer.)

Dan

0 Robert Wolfe over 13 years ago in reply to D E Ungar

Mastermind 7860 points

Dan,

More great suggestions/diagnosis.

I leave "Run to main on program load or restart" disabled, else it just goes right to the boot loader endless loop.

I broke in that endless loop, then loaded norwriter.out, and I was able to set the PC to c_int00 (address from the map file). After hitting go, I got the old, familiar request for the path to the bin file, etc. :) After entering the path, and hitting run, the program got bogged down, and all the flash addresses in the memory window showed the repeated pattern again. And that's likely because, as you suggest, the requisite initialization code is not there. So I'll work on adding that in, and report back (this is a home project, which doesn't always allow the time required for making progress as quickly as I'd like).

Thanks,

Robert

0 D E Ungar over 13 years ago in reply to Robert Wolfe

Intellectual 680 points

Well, inch by inch you're progressing.

The only thing that comes to my mind at the moment is to check the Idle Status Register (I think you can do so via the Memory view in I/O space) to see if EMIF clocking is or is not disabled. Somehow, on my board, I managed to run nor_writer after hosing the Flash and then powering the board on and off, thus wiping out any previous Idle Control settings and allowing the boot loader to reconfigure everything according to its wont.

Dan

0 D E Ungar over 13 years ago in reply to D E Ungar

Intellectual 680 points

OK, it appears there is NOT a risk of disabling external memory data access - you can only idle the DPORT or IPORT clock if you also idle the CPU itself!

From TMS3320C5515 DSP System User's Guide (SPRUFX5):

1.5.3.1.2 Valid Idle Configurations
...
A bus error will be generated (BERR = 1 in IFR1) if you execute the idle instruction under any of the
following conditions and the idle command will not take effect:
1. If you fail to set IDLECFG = 0111 while setting any of these bits: DPORTI, XPORTI, IPORTI or
MPORTI.
2. If you set DPORTI, XPORTI, or IPORTI without also setting CPUI.

I just now reset the CPU in my ezDSP, after which I examined Memory view, I/O space words 0x000001 and 0x000002:
ICR = 0x0000; ISTR = 0x0000 = All clock domains are active (no clock domains are idled)

I then put a hardware breakpoint at the entry point of EZDSP_Sample and ran, thus executing the boot loader and stopping before executing any application code. At this time,
ICR = 0x028E; ISTR = 0x028E = Idle FFT accelerator and DMA memory port only. (These are the only clock domains that can be idled while the CPU is running.)

After then running EZDSP_Sample (the factory-installed version booted from Flash) for a few seconds and halting at an arbitrary point,
ICR = 0x032E; ISTR = 0x0000
In this case, the ICR appears to be configured to idle FFT accelerator, and both instruction and data access to external memory, but the ISTR indicates that this has not been executed and all clock domains are active.
Indeed, looking at USB_Stick_Sample\asm\vector.asm, I find the lines
*port(#IDLE_ICR) = #(RESERVED_ICR|IPORT_IDLE|HWA_IDLE|DPORT_IDLE)
idle
which, as noted above, is illegal, so the idle instruction fails.
Breaking at the first of these instructions and stepping through them, executing idle clears all bits in ISTR.
A sterling example of what not to include in example code supplied to your customers.

I guess you need to connect to target and load, then execute nor_writer, breaking after each Flash program / verify iteration and see where it is going wrong.

I believe you should be operating at a reasonable clock frequency if either

You have (following a CPU Reset) run, then halted the boot loader (which will configure the clock generator to ~36 MHz as described below) and you have not done a CPU Reset before subsequently starting nor_writer
OnTargetConnect() in your GEL file includes ProgramPLL_100MHz() and you have not done a CPU Reset before starting nor_writer - Make sure that if OnTargetConnect() executes GEL_Reset() it follows up with ProgramPLL_100MHz()

Both of these assume your GEL file does nothing in OnPreFileLoaded() and OnFileLoaded().

From Using the TMS320C5515/14/05/04 Bootloader (SPRABD7):

2.2 Boot Devices
The C5515/14/05/04 has a fixed order in which it checks for a valid boot-image on each supported boot
device. The device order is NOR Flash, NAND Flash, 16-bit SPI EEPROM, I2C EEPROM, and MMC/SD.
The first device with valid boot-image is used to load and execute user code.
If none of these devices has a valid boot-image, the bootloader modifies the CPU clock setup as follows:
• If CLK_SEL = 0, the bootloader powers up the PLL and sets its output frequency to 36.864 MHz
(multiply 32768 Hz RTC clock by 1125).
• If CLK_SEL = 1, the bootloader powers up the PLL and sets it to multiply CLKIN by 3.
This CPU clock setup change is required to meet the minimum frequency needed by the USB module.
Next, the bootloader goes into an endless loop checking for data received on the USB.

Dan

0 D E Ungar over 13 years ago in reply to D E Ungar

Intellectual 680 points

Just another thought on the matter of programming off-chip NOR Flash:

In addition to the various clock configuration considerations, there are also configuration registers for the External Memory InterFace (EMIF). See TMS320C5515/14/05/04 DSP External Memory Interface (EMIF) User's Guide (SPRUGU6). I haven't looked into them, so I can't comment on potential pitfalls or what values I would expect them to be, but you could compare my hex dumps below to your ezDSP to see if you spot anything unexpected.

Also, take note of forum posting http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/p/66082/239155.aspx#239155

When I look at Memory view, I/O space containing EMIF-related registers , below is what I see on my ezDSP that has the factory EZDSP_Sample in Flash. The EMIF-related registers don't appear to change when I reset and run, but for some reason I am unable to view most of them after running the boot loader and halting at the entry point to EZDSP_Sample; this may be a quirk of the emulator; I don't know.

Dan

Upon CPU Reset:

0x001000:

REV STATUS AWCCR1AWCCR2

0205 C000 0205 C000 0080 F0E4 0080 F0E4 0620 0000 0620 0000 007D 0000 007D 0000

ACS2CR1ACS2CR2

FFFD 3FFF FFFD 3FFF FFFD 3FFF FFFD 3FFF FFFD 3FFF FFFD 3FFF FFFD 3FFF FFFD 3FFF

5810 4221 5810 4221 0002 0000 0002 0000 0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

EIRR EIMR EIMSR EIMCR

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0400 0000 0400 0000

0003 0000 0003 0000 0000 0000 0000 0000 FDFE FCFC FDFE FCFC 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000 2091 0000 2091 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

0002 0000 0002 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

0x001C10:

CCR1

0000 0000 0000 0000 0001 0000 0001 3F3F 603F FFFC 0100 0000 0000 0000 0000 0011

ECDR

8BE8 8000 080E 0000 000B 0000 0001 0000 FFFF 0000 FFFF FFFF FFFF FFFF FFFF 0000

ESCR

0000 0000 A04C 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

Upon running boot loader:

0x001000:

0BAD 0BAD 0BAD 0BAD 0BAD 0BAD 0BAD 0BAD 0BAD 0BAD 0BAD 0BAD 0BAD 0BAD 0BAD 0BAD

0x001C10:

0000 0000 0000 0000 0001 0000 0001 3F3F 603F FFFC 0100 0000 0000 0000 0000 0011

8BB4 8000 080E 0207 000B 0000 0001 0000 FFFF 0000 FFFF FFFF FFFF FFFF FFFF 0000

0000 0000 A04C 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

After running & halting EZDSP_Sample:

0x001000:

0205 C000 0205 C000 0080 F0E4 0080 F0E4 0620 0000 0620 0000 007D 0000 007D 0000

FFFD 3FFF FFFD 3FFF FFFD 3FFF FFFD 3FFF FFFD 3FFF FFFD 3FFF FFFD 3FFF FFFD 3FFF