Programming TMS320DM6437 Flash with CCSv4

Anybody please reply to this post!

Illyas,

CCS does not support programming of External Flash.  It has support for programming on chip flash but not external flash.  

Someone in the device forum may be able to provide you with a method to program the flash.  I will move the thread there and flag it for the moderator.

John

Thanks for the reply John,

Actually I m facing the problem to program even in the Internal RAM for debugging.

After I load my program or Debug the PC Program Counter doesn't point to main but it points somewhere else.

And from there the target goes to unknown state.

And I get the Data verification error at a fixed address i.e., 0x10808AB0 if the code is mapped at 0x10800000 in the linker command file.

Do you think I m missing out some compiler/linker/build/debug settings??? or else it might be a hardware issue???

I am not familiar with the memory settings of the device and what you have to do to initialize the memory.  Have you tried relocating your code to SRAM at 0x42000000 or external DDR2?  

The dm6437 has L2 RAM at the memory location where you are getting the failure.  If you are failing while trying to load code through an emulator, you may not have properly configured the chip.  L2 can be configured to be setup as cache or SRAM.  In your gel file, make sure you have setup L2 as SRAM if you want to locate code there.

Hi,

My L1 is setup as cache and all L2 as SRAM .

The .gel output on Setup_Cache is like this,

C64XP_0: GEL Output: Setup Cache
C64XP_0: GEL Output: (L1P = 32K) +
C64XP_0: GEL Output: (L1D = 32K) +
C64XP_0: GEL Output: (L2 = ALL SRAM)...
C64XP_0: GEL Output: [Done]
C64XP_0: GEL Output: Disable EDMA events
C64XP_0: GEL Output:

In the debug perspective, tools – memory map

I find my L2 RAM mapped at this adress.

GEL_MapAddStr( 0x10800000, 0, 0x00020000, "R|W|AS4", 0 ); // L2 Cache

What else might be the problem?

If you post your gel & your linker command file I will take a look sometime.

2604.Files.rar

I have attached the .gel, linker command file and also my console output.

"When i launch debug mode, load my gel file. From View->Memory Window, if I write some data into RAM loacation

or into some CPU registers they are not getting changed. They remain default" What is the problem here?

I need some clarifications regarding .GEL files.

1) When I load my gel file where does it execute from? Is that from L1/L2 RAM or from emulation software?

2) If it executes from L1/L2 RAM then how can it setup the RAM/Cache? Also how is it possible for our code to be loaded into L2 RAM?

3) What is the sequence of execution among bootloader, gel script, and user program?

Illyas,

GEL is a debugger script and is not a target program so it does not execute out of memory on the device.

GEL files are comprised of functions.  These functions execute either when you tell the debugger to execute them or tied to specific actions in the debugger.

Startup() runs when the debugger is started, even before the target is connected.  Typically used to setup the memory map for the debugger

OnTargetConnect() runs when the debugger has connected to the device.  Typically used to setup clocks, disable watchdogs...

OnFileLoaded() runs after a program has been loaded

OnPreFileLoaded() runs just before a program is loaded

OnReset() runs after a reset

...

Any actions in the GEL functions that access the target will take place via JTAG.

Here are some links that provide more information on GEL.  There is also information in the online help.

http://processors.wiki.ti.com/index.php/GEL

http://www.ti.com/lit/an/spraa74a/spraa74a.pdf

Regards,

John

As John said, a gel isn't run "on the chip", it is run through the emulator.  The idea is to make all the memory configuration easy to understand so the chip is ready to run your code and nothing crashes, but it is confusing until you get used to it.  The idea is, when you execute the bootloader and run your program without the emulator attached, all the configuration that is done in the gel file will have to be done in your code.  So the execution order is either bootloader > user program OR gel > program loaded through emulator.

You want to make sure you load the gel file into CCS before you connect to your target, so that the "on target connect" & "on program download" scripts actually run.  If things still aren't running correct, we will have to dig a little deeper.  Typically if you try to write something into memory when connected with the emulator and it doesn't work, you either have an error in your setup, or the memory is actually configured as cache instead of ram and its not really "write-able".

Thanks Matt!

I m following the exact sequence as you said.

I launch debugger ->  Load the gel file -> Power cycle target brd -> Connect the target

Upon this, OnTargetConnect script gets executed. Also other gel functions like Cache, Pll setup, Memory Map, Bootmode read is done.

(I use Emulation Boot Mode for debug[BOOTMODE: 0000]. What is the exact bootmode to be selected to program or Debug through EMULATOR)

Now when I read Memory @0x10800000 i.e., L2RAM (as configured in .gel) I see some unknown data existing till its end.

Now when I try to clear/write into L2 RAM it doesn't update. And I see the cache config registers turn red.

WHERE AS. In the same setup when I write into L1PRAM @ 0x10E08000. It writes successfully.

So, when I change my memory section to L1P RAM and load program. It loads. BUT IT DOESN"T RUN. PC doesn't point to main.

Also I m not able to write into CACHE config registers in the register view. If I write 0x0 it gets updated as 0x76xxxxxx(something like that).

As I just wanted all my L2 to be configured as RAM in Normal mode. No Invalidation, No Writebacks.

With this can you diagonise what the problem could be?

I would set the boot switches on your board to bootmode 0 when debugging.

First off, you should be aware that there are several of the register views that are INCORRECT.  Unfortunately, the cache config registers are one of them.  You will have to open a memory window and manually type in their address to see or modify their contents through the debugger.  =)  Maybe TI will get around to fixing that one of these days, but it's been a problem for the 3 years I've been using the dm6435.

You should also be aware that when you load your program, it will start at the c_init routine.  You can use the debugger "Go Main" function to run through the c_init program until it hits your main() entry point.

I don't know why you can't modify L2... my theory is that it is configured as cache instead of ram.  You will want to confirm the contents of the L2CFG register to see if that is the case.