processor initialization using HexAIS

Robert56682 said:

Brad Griffis has indicated (in a different thread) "When you migrate to a stand-alone application, that setup should be handled as part of the AIS headers (i.e. by the ROM code). Structuring your code in this way allows you to link/load code and data directly into DDR. Otherwise, you end up with sections like .cinit which get used only one time ever (i.e. before main) taking up precious internal RAM." I don't quite understand that, and was hoping initially for more of an explanation, and then to get help with some of the HexAIS settings in the flash .ini file.

The ROM bootloader is responsible for copying your application from non-volatile memory to RAM.  If you've linked code or initialized data (like cinit) into external RAM and you're expecting your application to configure the RAM, then that means the EMIF has not yet been configured at the time the ROM bootloader is copying your code into external RAM.  Therefore it won't work...  If you use the AIS commands to configure external RAM, that will be done by the ROM bootloader immediately prior to copying any code to external RAM.  So now in this case you're able to leverage external RAM immediately. 

In my mind, I consider the role of the gel file during development to be analogous to the role of the AIS commands in a production system.  Both operate just prior to loading actual code, and their main goal is to configure PLL and DDR.  That way, code/data can be placed anywhere in the system.

So related to .cinit, that is a section used one time ever (in the c_int00 function that executes before main).  So that's a section you definitely want allocated to external RAM.  That way you're not taking up internal RAM with data that will never be used again.  Potentially you could do something fancy like a data overlay where you repurpose that memory after main, but I think it's cleaner/easier to just stick it somewhere in external memory. 

Robert56682 said:

Also, is it beneficial to do just the PLL and mDDR via HexAIS, or additional components of the processor setup and initialization?

You can optionally do things like pinmuxing through HexAIS, though personally I like setting that up in the application.  You can also configure PSC through HexAIS.  If you already are doing so through the application then you could just leave it.  Though if you're starting from scratch, it's nice to leverage some of these routines through HexAIS rather than writing all new code to do it.

Thanks, that clears a lot up.  I'm going to start in on the PLL and mDDR configuration, via the HexAIS .ini file.  And I'm referencing this section, for the PLL1 and EMIF first (hard to get proper formatting to line up on E2E with cut and paste, so I snapped a picture):

I am using mDDR, so will need the second section.  But starting with the first section - the comments preceding the values imply that PLL1CFG0 and PLL1CFG1 should just be set the same as the PLL1CFG.  First question is should they both be the same PLL1CFG value?  That's not what was shown in the example values after the comments.  Also, to find the values I have, I loaded my application in CCS, had it perform the PLL application initialization, and then went looking for this register, and its value, but could not find it.  I'm maybe overlooking it?  Under CCS PLL1, here is all I see:

Robert

All the commands in this HexAIS configuration file directly map to AIS commands.  So the best way to understand them to is look at the AIS documentation in SPRAB41.  Here's a snippet:

So in particular, you can see that each of the two PLL1 configuration arguments actually is composed of multiple register values which will be written.  So you should take your existing register values, and use those numbers to construct the corresponding PLL configuration arguments.

Ok, that doc/table cleared some of it up.  And I've gone through and took a stab at most registers, with values as shown below:

For the first set, the PLL were pretty straightforward, after referencing that table.  For the rest of that first set (ddr-related), I just ran my initialization, and picked them off from the associated register/memory location in CCS.  Hopefully that is legit.  For the second set, when looking at 0x01E2C004, my data was 0, not the 3 they had in the template .ini file.  But something tells me that isn't right ... that the 3 is needed at configuration time, and goes to 0 after config is done? (so I should put the 3 back in).

Robert

You need to uncomment the AIS_Set command, i.e. remove the leading semicolon.  Same for the EMIF3DDR command.

Robert,

If you are unfamiliar with the scripting syntax in HexAIS, we also provide a GUI based tool for Windows call AISGen tool that only requires users to provide configuration settings and the tool will insert the required AIS commands in the AIS image.

I have provided some screenshots 

the tool also provides reference initialization for mDDR that can be used on the TI supported EVM and DDR2 setting for the low cost OMAPL138 platform that we support.

Regards,

Rahul

Rahul Prabhu said:

Robert,

If you are unfamiliar with the scripting syntax in HexAIS, we also provide a GUI based tool for Windows call AISGen tool

Thanks.  I seem to have the hang of the scripting now, with some help from Brad.  But I'll keep this in mind.

Robert

Brad Griffis said:

You need to uncomment the AIS_Set command, i.e. remove the leading semicolon.  Same for the EMIF3DDR command.

I took out everything, except what is intended to be configured, as shown below.  Can you have a look, to see if it seems ok?  I flashed an image successfully with it, but it is still an application that doesn't use external RAM for storage, etc (.cinit).  I plan to try that next.

Thanks,

Robert

I recommend that you just sanity check that all the registers are configured the same for both the gel file and the "real" application.  Do you see a value of 3 at address 0x01E2C004 now?

Brad Griffis said:

I recommend that you just sanity check that all the registers are configured the same for both the gel file and the "real" application.  Do you see a value of 3 at address 0x01E2C004 now?

I have never really used a GEL file for setup, having done all that initialization in the app code from the start, so don't have that comparison.  But what I have done is set a break point at the end of my initialization, during emulation, which includes all the clock and mDDR, and got the following for 0x01E2C004:

As we see, that register has a value of 0.  Maybe I've not set the DDR_SLEW properly in the app initialization, when it was needed, since it seems a 3 should be there.  But yet the SDRAM/mDDR does appear to be working, when running my app.

I did the same for the other registers, as follows:

This is where the values in my HexAIS ini file came from.

Robert

As another data point, I loaded the OMAPL138_DSP.gel file, and ran Frequency Settings->Core_300Mhz_mDDR_132Mhz, which most closely approximates my target.  And location 0x01E2C004 still had a value of 0.  The SYSCFG_VTIPIO_CTL value was a little different than my app initialization value, but that's probably not a concern.

Please advise,

Robert

The DDR_SLEW register is improperly configured for mDDR.  It should have a value of 0x30.  Can you try just poking a value of 0x30 into the memory window?  Does it "stick"?  It should.

The AIS_SET command being used in your ini file is utilizing a read-modify-write format for that DDR_SLEW register.  Perhaps try this alternate syntax:

[AIS_Set]

TYPE = 0x00000002

ADDRESS = 0x01E2C004

DATA = 0x00000030

SLEEP = 0x00000000

This should be just a straight 32-bit write of the value 0x00000030 to address 0x01E2C004.

PS.  I was looking at the gel file you mentioned.  Within the DEVICE_DDRConfig function I see the following code:

   // Settings that change depending on DDR2 or MDDR

   if( ddr_type == DDR2 ) {

     DDR_SLEW = 0x00000000;                   // Disable Pull Downs, Disable LVCMOS Rx

     tmp_SDCR = (0x0               << 25)  |  // MSDRAMEN

                (0x1               << 20);    // DDR2EN

     GEL_TextOut("\tUsing DDR2 settings\n","Output",1,1,1);

   }

   else if( ddr_type == MDDR ) {

     DDR_SLEW = 0x00000030;                   // Enable Pull Downs, Enable LVCMOS Rx

     tmp_SDCR = (0x1               << 25)  |  // MSDRAMEN

                (0x0               << 20);    // DDR2EN

     GEL_TextOut("\tUsing mDDR settings\n","Output",1,1,1);

   }

The ddr_type passed into the function is MDDR so it *looks* like it should be  setting DDR_SLEW = 0x00000030.  Do you see those lines of code in the gel file you tested?

Brad Griffis said:

The DDR_SLEW register is improperly configured for mDDR.  It should have a value of 0x30.  Can you try just poking a value of 0x30 into the memory window?  Does it "stick"?  It should.

Yeah, I see now too, that the example value of 0x3 should have been 0x30.  I was able to just poke it in, and it did stick.

Since then, I've been trying various things.  Initially, I realized that I hadn't set PLL0CFG values in the ini, so added them in.  Until that, my 250 millsecond led blinks, were more like 2 seconds.  I used the OMAPL1x_debug.gel file suggested in a different thread, to see the PLL0 clocks were not initiated.

However, I was trying some other things, still just focused on getting the basic program in, with intentions to try the mDDR tests after (.cinit in external RAM, which it still isn't in my application).  I was going to try [AIS_Set], using both the example .ini and what you had suggested, as shown below.  But somewhere along the way, when I flashed in, it totally hosed my board, with no clue.  As soon as power goes on, all the LEDs go bright red, and I can no longer connect via emulation.  

Any advice on how to get our of this predicament?, as I can't afford to brick one of my very limited # of target boards.  Is there any prescription for resetting some default states in the processor, when the emulator no longer connects?

Thanks,

Robert

Brad Griffis said:

The ddr_type passed into the function is MDDR so it *looks* like it should be  setting DDR_SLEW = 0x00000030.  Do you see those lines of code in the gel file you tested?

Brad Griffis said:

You will need to modify your boot mode to something else such that it stops reading in the configuration that is locking things up. Then you should be able to connect with JTAG and re-flash your board.

My apologies if overlooking something obvious - but how to change the boot mode, without connection to the processor (via JTAG)?

Robert

If I look in CCS 6.2 at <ccs_install_dir>\ccsv6\ccs_base\emulation\boards\evmomapl138\gel\ then I have a file called EVMOMAPL138_DSP.gel.

• EVMOMAPL138_DSP.gel

The boot mode is determined by the state of the pins BOOT[7:0].  Please refer to Appendix A of sprab41.

Brad Griffis said:

If I look in CCS 6.2 at <ccs_install_dir>\ccsv6\ccs_base\emulation\boards\evmomapl138\gel\ then I have a file called EVMOMAPL138_DSP.gel.

• (Please visit the site to view this file)

Ok, thanks.  I don't have the evmomapl138 directory there, on the computer I'm working off.

Brad Griffis said:

The boot mode is determined by the state of the pins BOOT[7:0].  Please refer to Appendix A of sprab41.

Had to physically adjust boot pins on the target, to get out of the bad mode, and flash in different code.  After doing so, it was determined that the problem came from using the existing method in the OMAP-L138.ini file, supplied with the HexAIS tools, to write the correct 0x30 into location 0x01E2C004, like this:

[AIS_Set]                                              ; bad
TYPE = 0x00050403
ADDRESS = 0x01E2C004
DATA = 0x00000030
SLEEP = 0x00000000

That file initially had it writing 0x3 instead, but we have seen from the literature, that does nothing/unsupported.  0x30 is needed to enable the pulldowns, but cannot be written using the method above, from the ini file supplied.

However, using the direct memory write suggested appears to be ok:

[AIS_Set]
TYPE = 0x00000002
ADDRESS = 0x01E2C004
DATA = 0x00000030
SLEEP = 0x00000000

I'll next try to see if immediate use of external memory is successful using this final ini file:

by changing .cinit to external ram, in the tcf file/bios.

Robert

I have put .cinit into external, mDDR space, from previously RAM. The flash of the part occurred, but nothing happens (no test LEDs, per simple logic being used as feedback). I then went to emulation. I've never really used a GEL for setup, but assume I will need to now, since the basic underlying program now needs it, per .cinit. So I made use of the OMAP138_DSP.gel routines, and specifically Frequency-Settings->Core_300Mhz_mDDR_132Mhz. I first called that script, for mDDR setup, then tried to load and run my code. If I didn't call that GEL routine, I was getting File Loader: Verification errors, which is probably understandable, since its looking to load to mDDR, which is not configured.

With the gel routine, and then loading the program, the Debug window/session says "Running - A Reset Occurred on the Target", the it switches to "Running", but it doesn't appear to be hitting any of my code, and breaking results in it stopping at a location, for example, 0x713d9a. If I then hit Restart, it goes to c_int00(), and if I hit F6, it next goes to cmmcfg.s62, where it wants to run the BIOS init routines, starting with GBL_init. However, when I hit F6 there, it goes to 0x1183412c, and when I say View Disassembly, the Disassembly window shows some locations around 1C. F8s just keep breaking in locations around 0x11835428.

Any advice on how to debug, or progress past this problem? would be appreciated

Robert

Let's stay with the gel file for now. It's quicker/easier to debug since it doesn't require you to reflash the device each time:

1. Connect to target, running the gel setup.

2. Load your code, BUT DO NOT RUN.

3. Go to external memory.  Use the map file to determine the placement of that cinit file and look at it in the memory window.

4. Run your code.  Halt and look at that same location again.  Is the data still there, or did it get corrupted or perhaps zeroed?

As a side note, are you POSITIVE that you have removed all code related to PLL1 initialization and DDR initialization from your run-time code?

Brad Griffis said:

Let's stay with the gel file for now. It's quicker/easier to debug since it doesn't require you to reflash the device each time:

1. Connect to target, running the gel setup.

2. Load your code, BUT DO NOT RUN.

3. Go to external memory.  Use the map file to determine the placement of that cinit file and look at it in the memory window.

4. Run your code.  Halt and look at that same location again.  Is the data still there, or did it get corrupted or perhaps zeroed?

The data is pretty much completely changed.

Brad Griffis said:

As a side note, are you POSITIVE that you have removed all code related to PLL1 initialization and DDR initialization from your run-time code?

Doh.  I had mistakenly left in the PLL and DDR configuration.  But I repeated everything, including your prescription above, with them removed, with no change in results.  That might be because the program is never making it to my initialization routine, where the calls are made to initialize the PLL and DDR.

Robert

Brad Griffis said:

Let's stay with this same testing format of checking the .cinit data in DDR. Can you step through your code to determine at what point the cinit data gets clobbered?

I've been trying to get through all the startup code, to see where it goes into the weeds.  But its become a pretty time consuming process, and fruitless so far.  Part of the reason is that standard F5 or F6 stepping doesn't appear to work in the disassembly window, for this startup code, beginning with c_int00.  One F5 or F6 sends it into the weeds.  But if I set breakpoints ahead of time, it will catch those.  But the problem is I don't know where to set the breakpoints for the next time.  Could be going anywhere in the startup code.  For example, my latest progress is that it hits this label 4 times.  

At the 4th, a F5 or F6 sends it off.  

Is there any easier way to do this?

Robert

Brad Griffis said:

The first big question is whether the data is still intact when you get to main. Can you just put a breakpoint in main and run to it?

It never gets to main.  With a single break-point at main, it never hits it, and if I suspend, it's normally somewhere in the 0x713D9A region.

Brad Griffis said:

When you rebuild all do you get any linker warnings?

none

Brad Griffis said:

When you rebuild all do you get any linker warnings?

The next best thing I can suggest is to create a new "empty" project (e.g. a "hello world" or something minimal) and see if you can get it to successfully make it to main. Or along similar lines, start stripping stuff out of your project to figure out where it starts working.

All the code that runs prior to main is provided in source form.  Yes, you should be able to step through it.

• Non-BIOS Projects: Inside the compiler directory see the boot.c file and step through the c_int00 code.  In CCS this exists for example at ccsv6\tools\compiler\c6000_7.4.18\lib\src\boot.c.
• SYSBIOS Projects: packages\ti\targets\rts6000\boot.c

One other thing that came to mind is to be absolutely sure that memory is being retained in the first place.  After you have loaded the code into memory and checked it through the memory window, can you wait a few minutes and then hit refresh to make sure nothing has changed?

Brad Griffis said:

All the code that runs prior to main is provided in source form.  Yes, you should be able to step through it.

• Non-BIOS Projects: Inside the compiler directory see the boot.c file and step through the c_int00 code.  In CCS this exists for example at ccsv6\tools\compiler\c6000_7.4.18\lib\src\boot.c.
• SYSBIOS Projects: packages\ti\targets\rts6000\boot.c

One other thing that came to mind is to be absolutely sure that memory is being retained in the first place.  After you have loaded the code into memory and checked it through the memory window, can you wait a few minutes and then hit refresh to make sure nothing has changed?

I'd like to build in boot.c in my project, so I can turn on debugging (-g), but it is complaining about dual definition (my local boot.obj and the library version).  Would you know how to ask CCS linker to use just the local boot.obj?

Robert

Brad Griffis said:

I think that relates to a build option. Specifically in the linker options go to the "File Search Path" dialog. I have a box called "reread libraries". I think if you uncheck that option that will do the trick.

Tried that, but no luck ... still flags dual definitions (__stack, _c_int00)

Sorry, not sure on the dual definitions.  You could either start a separate thread on that topic in the compiler forum or else try a different means of debug, e.g. whittling down to a simpler project for starters.

Hi Robert,

I did an experiment with a new BIOS 5 project to see if I could get it to build okay but I didn't run it on hardware.

Using CCSv6.1.1, I created a new CCS project and used the new project template DSP/BIOS v5.xx Examples -> evm6748 Examples -> hello example. After the project was created I built it with no modifications just to make sure it builds okay out of the box, it did. I then copied two source files directly into my project, notice copied and not referenced. The files are:

C:\ti\bios_5_42_01_09\packages\ti\bios\src\aux62\boot.c

C:\ti\bios_5_42_01_09\packages\ti\bios\src\aux62\autoinit.c

After that, I had a copy of each file in my local project, I did a rebuild all all and it built okay. I didn't actually run it on anything, don't have any hardware handy at the moment but it did build without errors. Here's my build output...

**** Build of configuration Debug for project test2 ****

"C:\\CCSv6.1.1.00022\\ccsv6\\utils\\bin\\gmake" -k all
'Building file: ../hello.tcf'
'Invoking: TConf'
"C:/TI/bios_5_42_01_09/xdctools/tconf" -b -Dconfig.importPath="C:/TI/bios_5_42_01_09/packages;" "../hello.tcf"
'Finished building: ../hello.tcf'
' '
'Building file: ../autoinit.c'
'Invoking: C6000 Compiler'
"C:/CCSv6.1.1.00022/ccsv6/tools/compiler/c6000_7.4.14/bin/cl6x" -mv6740 --abi=coffabi -g --include_path="C:/CCSv6.1.1.00022/ccsv6/tools/compiler/c6000_7.4.14/include" --include_path="C:/Desktop/temp/CCSv6_Workspace/test2/Debug" --include_path="C:/TI/bios_5_42_01_09/packages/ti/bios/include" --include_path="C:/TI/bios_5_42_01_09/packages/ti/rtdx/include/c6000" --display_error_number --diag_warning=225 --diag_wrap=off --preproc_with_compile --preproc_dependency="autoinit.pp"  "../autoinit.c"
'Finished building: ../autoinit.c'
' '
'Building file: ../boot.c'
'Invoking: C6000 Compiler'
"C:/CCSv6.1.1.00022/ccsv6/tools/compiler/c6000_7.4.14/bin/cl6x" -mv6740 --abi=coffabi -g --include_path="C:/CCSv6.1.1.00022/ccsv6/tools/compiler/c6000_7.4.14/include" --include_path="C:/Desktop/temp/CCSv6_Workspace/test2/Debug" --include_path="C:/TI/bios_5_42_01_09/packages/ti/bios/include" --include_path="C:/TI/bios_5_42_01_09/packages/ti/rtdx/include/c6000" --display_error_number --diag_warning=225 --diag_wrap=off --preproc_with_compile --preproc_dependency="boot.pp"  "../boot.c"
'Finished building: ../boot.c'
' '
'Building file: ../hello.c'
'Invoking: C6000 Compiler'
"C:/CCSv6.1.1.00022/ccsv6/tools/compiler/c6000_7.4.14/bin/cl6x" -mv6740 --abi=coffabi -g --include_path="C:/CCSv6.1.1.00022/ccsv6/tools/compiler/c6000_7.4.14/include" --include_path="C:/Desktop/temp/CCSv6_Workspace/test2/Debug" --include_path="C:/TI/bios_5_42_01_09/packages/ti/bios/include" --include_path="C:/TI/bios_5_42_01_09/packages/ti/rtdx/include/c6000" --display_error_number --diag_warning=225 --diag_wrap=off --preproc_with_compile --preproc_dependency="hello.pp"  "../hello.c"
'Finished building: ../hello.c'
' '
'Building file: hellocfg.s??'
'Invoking: C6000 Compiler'
"C:/CCSv6.1.1.00022/ccsv6/tools/compiler/c6000_7.4.14/bin/cl6x" -mv6740 --abi=coffabi -g --include_path="C:/CCSv6.1.1.00022/ccsv6/tools/compiler/c6000_7.4.14/include" --include_path="C:/Desktop/temp/CCSv6_Workspace/test2/Debug" --include_path="C:/TI/bios_5_42_01_09/packages/ti/bios/include" --include_path="C:/TI/bios_5_42_01_09/packages/ti/rtdx/include/c6000" --display_error_number --diag_warning=225 --diag_wrap=off --preproc_with_compile --preproc_dependency="hellocfg.pp"  "hellocfg.s??"
'Finished building: hellocfg.s??'
' '
'Building file: hellocfg_c.c'
'Invoking: C6000 Compiler'
"C:/CCSv6.1.1.00022/ccsv6/tools/compiler/c6000_7.4.14/bin/cl6x" -mv6740 --abi=coffabi -g --include_path="C:/CCSv6.1.1.00022/ccsv6/tools/compiler/c6000_7.4.14/include" --include_path="C:/Desktop/temp/CCSv6_Workspace/test2/Debug" --include_path="C:/TI/bios_5_42_01_09/packages/ti/bios/include" --include_path="C:/TI/bios_5_42_01_09/packages/ti/rtdx/include/c6000" --display_error_number --diag_warning=225 --diag_wrap=off --preproc_with_compile --preproc_dependency="hellocfg_c.pp"  "hellocfg_c.c"
'Finished building: hellocfg_c.c'
' '
'Building target: test2.out'
'Invoking: C6000 Linker'
"C:/CCSv6.1.1.00022/ccsv6/tools/compiler/c6000_7.4.14/bin/cl6x" -mv6740 --abi=coffabi -g --display_error_number --diag_warning=225 --diag_wrap=off -z -m"test2.map" -i"C:/CCSv6.1.1.00022/ccsv6/tools/compiler/c6000_7.4.14/lib" -i"C:/CCSv6.1.1.00022/ccsv6/tools/compiler/c6000_7.4.14/include" -i"C:/TI/bios_5_42_01_09/packages/ti/rtdx/lib/c6000" -i"C:/TI/bios_5_42_01_09/packages/ti/bios/lib" --reread_libs --warn_sections --display_error_number --diag_wrap=off --xml_link_info="test2_linkInfo.xml" --rom_model -o "test2.out" "./autoinit.obj" "./boot.obj" "./hello.obj" "./hellocfg.obj" "./hellocfg_c.obj" -l"./hellocfg.cmd" -l"libc.a"
<Linking>
'Finished building target: test2.out'
' '

**** Build Finished ****

Brad Caldwell said:

Hi Robert,

I did an experiment with a new BIOS 5 project to see if I could get it to build okay but I didn't run it on hardware.

Thanks, that gets me past the linker problem, and able to start debugging the start-up issue.

Robert

Sorry I wasn't able to make progress on this ... got diverted.

But after picking it back up again, the latest is that it seems the .cinit data is getting loaded improperly or incompletely into external memory.  The attached picture shows that the autoinit routine goes through the cinit memory space, getting the 1) length 2) destination 3) value for each of the initialization values.  But what's shown is that it's ok for 3 iterations.  But the 4th, after the 16 word initialization ... at 0xc0200038 ... doesn't start have it's data ... it only has the length (4) and destination (11835704).  The routine looks at the next block for the data, etc, and everything gets thrown off.  

Please advise.

Robert

At first glance, that all looks ok to me.

• Can you look in the map file to see what variable exists at 0x11835704, i.e the destination of that 4th record?  And perhaps it might be useful to know what is at 0x1181D6FC or 0x11835928.  Those look like they MIGHT be intended as future records, though the table looks messed up to me.
• Can you get a shot of the same cinit table when it's allocated to internal memory? Ideally you could do this such that none of the addresses change.  Otherwise this will be hard to see what changed if all the numbers are different.  I think as long as cinit is listed last in your linker command file SECTIONS, then it should work out...

Brad Griffis said:

At first glance, that all looks ok to me.

• Can you look in the map file to see what variable exists at 0x11835704, i.e the destination of that 4th record?  

  11835704 __HOOK_knlId

  And perhaps it might be useful to know what is at 0x1181D6FC

  1181d6fc _CLK_inputClock

  or 0x11835928.  

  11835928 _CLK_htimePerLtime

  Those look like they MIGHT be intended as future records, though the table looks messed up to me.
• Can you get a shot of the same cinit table when it's allocated to internal memory? Ideally you could do this such that none of the addresses change.  Otherwise this will be hard to see what changed if all the numbers are different.  I think as long as cinit is listed last in your linker command file SECTIONS, then it should work out...

I attached a image of it under internal ram conditions.  The numbers did change, but there doesn't appear to be any entry blocks missing their data, as is the case in external ram.

cinit location is determined by CCS, no?  I just change the intended location, internal or external, via the tconf editor, Memory Section Manager.  The result of my build is a <project_name>cfg.cmd file, that is generated.  When building cinit into internal RAM, its has several entries before and after, as shown in the cut and paste below:  

.text: {} > IRAM

.cinit: {} > IRAM

.pmonchip: {} > IRAM

.switch: {} > IRAM

.gblinit: {} > IRAM

.sysinit: {} > IRAM

.trcdata: {} > IRAM

.hwi: {} > IRAM

.TSK_idle$stk: {
*(.TSK_idle$stk)
} > IRAM

When placing it in external RAM, it comes first:

SECTIONS {
.cinit: {} > DDR

.bss: {} > IRAM

.hwi_vec: {
*(.hwi_vec)
} align = 0x400, RUN_START(HWI_A_VECS) > IRAM

.far: {} > IRAM

.sysdata: {} > IRAM

.dsm: {} > IRAM

.sem: {} > IRAM

frt: {} > IRAM

This picture shows the DDR on the left, and L3 on the right.  The big difference I see, other than generally different numbers for dest/source/data, is that there is no case where the data is missing, for L3, compared to the case where it is for DDR.  And the problem with DDR seems to come after the iteration where it is working with 16 bytes, i.e. at 0xc0200038, where the next data set is missing its data.

Just out of curiosity, does the Load Address come into play here at all?  This shows that none of my sections have a separate load address.  Should that change for .cinit, in the case where it's in DDR?

Robert

Why are the addresses changing?  It is hard to draw any conclusions when the addresses are all changing.  That might mean that they represent different variables in which case we really can't compare the data.

After you load the code can you do a "verify" in CCS?  If I recall correctly, that's one of the options under the Run -> Load Program menu, i.e. to verify that the code in memory is all there.

Ok, now we are getting somewhere! If you are getting a verification error then that is a non-starter. It seems that you still have a DDR configuration issue.

I've attached the re-worked gel file, which should now match my application ddr config settings (and I have been able to use the ddr mem, when initializing it in the application code).  Can you have a look at this file, and specifically DEVICE_DDRConfig(), which I've re-worked, per my application settings, some of which we debugged in an earlier thread.  

My process now is:

1) build the output, after TCF set to put cinit in DDR

2) load the gel file

3) load the output file

4) under Scripts, call Frequency Settings->Core_300Mhz_mDDR_132Mhz

5) Run->Load->Verify Program

I then get this error, even after updating the gel file with my ddr config settings:

C674X_0: File Loader: Verification failed: Values at address 0xC0200005 do not match Please verify target memory and memory map.

dsp.gel

Another data point ... looking at the ddr memory, we see that the values at address 0xc0200000 through 0xc020003f are reproduced again starting at 0xc0200040.  That's why that last value from 0xc0200038 doesn't have it's data ... it's trounced on by the 0xc0200000 reproduction.    Looking through the memory, I see the same reproduction occurring, as can be seen from this picture (0x12341234 was my write, which showed the duplication)