Unable to set L2 cache on C6657

Kim,

It looks to me like you have data in 1st half of L2SRAM, (i.e. Start of 0x0080 0000 lenght of 0x0008 0000.)  When you enable 512K (1/2) of the L2SRAM as Cache, then 0x0080 0000 - 0x0087F FFFF will become cache.  

You'll need to change the start address of the allocation of the L2SRAM to be at 0x0088 0000 w/ length of 0x0008 0000 to make the 1st half available for caching, otherwise you'll trample your data.

Best Regards,

Chad

Hi Chad,

Thanks for the response.  I looked at the TMS320C6655/57 Fixed and Floating-Point Digital Signal Processor Data manual (sprs814A, page 100), and it shows that Cache would start at 0x00880000 and SRAM at 0x00800000 when using 512K cache.  Is the data sheet wrong?

Thanks,

Kim

Yes, you're correct.  I thought it was the other way around, but I was wrong.

What type of memory access activity do you have going on?  Are you sharing data between cores in MSMC RAM?  There may be some cache coherence issues going on.

Normally simply enabling L2 Cache would have no negative impact unless the memory space was already allocated or you have something requiring manual coherence operations.

Best Regards,

Chad

Hi Chad,

I am not using MSMC Ram at the moment.  I did do some more debugging (and modifying of my program) to see where something may stop working.

In main(), I have this:

.......

volatile CSL_CgemRegs* hCache = (CSL_CgemRegs*)CSL_CGEM0_5_REG_BASE_ADDRESS_REGS;

hCache->L2CFG |= 5;

SLCreateThread(DspTskMain, 4, 1024*10/*20*SL_DEFAULT_STACK_SIZE*/, "main", NULL);

BIOS_start();

.....

When I step over BIOS_start() that is when the program does not continue (I never hit a breakpoint I've set in DspTskMain).  If I set the L2CFG register to be 0 cache, then I will hit a breakpoint in my other thread (DSpTskMain).  Does this mean anything to you?

Thanks,

Kim

Kim,

Can you go to this point and then provide the following info.

PC value.

L2CFG Register Value.

Dump of the CorePac Registers.

Best Regards,
Chad

Hi Chad,

How do I get a dump of the corePac Register?  Is there a gel function example?  The L2CFG register is set to 0x30000005.

Thanks,

Kim

From the specific CorePac read the memory mapped location of the register 0x0184 0000

Best Regards,

Chad

The PC register says 0x800CC59C.  The memory mapped L2CFG register reads 0x03000005.  Does this seem correct?

thanks,

kim

Was this the value before you performed the modification to the L2CFG registers?  If so, it's indicating that it was already set to 512KB of cache enabled.

Best Regards,

Chad

Hi Chad,

L2CFG was set to 0x03000000 before I issued the command hCache->L2CFG |= 5;  After issuing that command, the memory mapped register is 0x03000005.

I did some back tracking and started with the TI's hello world example application.  It works great!  I added a line in the .cfg file to set the cache to 512KB (ti_sysbios_family_c66_Cache.initSize.l2Size = ti_sysbios_family_c66_Cache.L2Size_512K;) and by the time the main function is reached I see 0x03000005 in the L2CFG register.  Then I modified my code to be as trimmed down as possible (limiting the number of includes and commenting sections of code).  Now my program works!  I put the same line in my program's .cfg file (ti_sysbios_family_c66_Cache.initSize.l2Size = ti_sysbios_family_c66_Cache.L2Size_512K;) and the program reaches main(), with no problem and L2 cache is 512KB!  So my first post (above) said that my program was crashing, and with this trimmed out version of code it does not crash.  Something else must be wrong in my program then.  I'll try to slowly add code back in and see when I get to the crash and keep you posted.  But for now, it seems that setting cache works in my limited program!

Thanks,

kim

Can you pull the JTAG ID it's at 0x02620018?

If there's nothing in mapped into the space that the cache is taking up, then there should be no issues with enabling it later.  I'm not certain what's happening, maybe we can get more details with the experiments you're doing.

Best Regards,

Chad

Hi Chad,

0x02620018 reads 0xB97A02F.  Here is the simplified program I wrote:

#include <c6x.h>
#include <xdc/std.h>
#include <xdc/runtime/Error.h>
#include <xdc/runtime/System.h>
#include <ti/sysbios/BIOS.h>
#include <ti/sysbios/knl/Task.h>
#include <ti/sysbios/family/c66/Cache.h>

int DspTskMain(void *p)
{
//SLSleep(100);
Task_sleep(100);
while (1)
{

}

return 0;
}

int main()
{

volatile uint32_t *reg, regVal;

/* reg = (uint32_t*)(0x01840000);
*reg |= 5; // 512KB cache.
regVal = *reg; */

// below lines through Task_Create are an issue

Error_Block eb;
Error_init(&eb);
Task_Params tskAttrs;
Task_Params_init(&tskAttrs);
tskAttrs.stackSize = 1024*10;// 0x4000;
tskAttrs.arg0 = (UArg)NULL;
Task_create((Task_FuncPtr)DspTskMain, &tskAttrs, &eb);

BIOS_start();
return 0;
}

Even with this simplified code, I never get to main with the way it is (I'm initializing Cache to 512KB in the .cfg file).  If I comment out the lines regarding the Error and Task modules, I get to main when I run and through BIOS_start.

If I don't initialize Cache in the .cfg file, but initialize Cache with the "reg" variable above, I get to main when I run the code (and L2CFG gets set to 0x03000005), but the program locks up when I step over the line with "Task_create" in it.  When I then pause the program, disassembly shows that it is in some TI_decompress_rle_core function.  If I comment out the lines regarding the Error and Task modules, I get to main when I run and through BIOS_start (and L2CFG gets set to 0x03000005).

Then, if I leave Cache as 0KB and run the above code, I get to main, L2CFG is 0x03000000, Task_Create doesn't lock up the program, and I hit a breakpoint in DspTskMain thread!

I am using cgtools 7.4.2 and sysbios 6.35.01.29.  I've also attached my configuration file.

Thanks,

Kim

0118.8662.app.cfg

The original code contains too much stuff, which is why I am trying to simplify the problem with 

Moving this to the BIOS/RTOS forum.  I'm not sure what's going on here, there should be no issue enabling Cache if the memory space isn't used, but there may be some restrictions going on w/ BIOS so the BIOS team will need to take a look a this.

Best Regards,

Chad

I'm going to need a little time to read and digest this thread. What version of SYS/BIOS are you using?

Todd

Hi Todd,

I am using Sysbios version 6.35.1.29, with XDC version 3.25.0.48.  The main problem is that I cannot always set L2 cache on a c6657 device.  The last post of mine describes the main issue.  I've even tried the TI example name "typical" for targest set to ti.targets.elf.C66 and ti.platforms.evm6657.  I try to change the cache size in either the .cfg file or the main.c file.  When I change the cache size in the .cfg file, and then run the program, I don't get to the main function.  If I change the cache size in main(), with these lines of code (before Task_create):

Cache_Size mySize;

mySize.l1dSize = Cache_L1Size_32K;
mySize.l1pSize = Cache_L1Size_32K;
mySize.l2Size = Cache_L2Size_512K;
Cache_setSize(&mySize);

then the program halts when Task_create is executed.

Thanks,

Kim

Any suggestions on this?

Thanks,

Kim

Kim,
I remember that a couple of bugs related to cache were fixed in SYS/BIOS since 6.35.01.29. I am not sure if your problem is one of them, but it's relatively easy to check. There are two pieces of data related to cache, and they have to match.
The first place to check is your memory map in the map file. What you already posted indicates that the cache configuration is:
L2 - 512K, L1D - 16K, L1P - 32K
Now, look for a C file in the directory package/cfg of your project. Open it and search for initSize. You should be able to find a structure similar to this one:

__FAR__ const CT__ti_sysbios_family_c66_Cache_initSize ti_sysbios_family_c66_Cache_initSize__C = {
    ti_sysbios_family_c66_Cache_L1Size_32K, /* l1pSize */
    ti_sysbios_family_c66_Cache_L1Size_16K, /* l1dSize */
    ti_sysbios_family_c66_Cache_L2Size_512K, /* l2Size */
};

Try checking these values with or without configuring cache in your CFG script. In general, you should not need to configure cache in your CFG script, except as a workaround for a bug in SYS/BIOS. Let's see what values you get, and then we'll proceed from there.

Hi Sasha,

The initSize in the package/cfg says ti_sysbios_family_c66_Cache_L2Size_0K.  So they do not match.  I can only get them to match if I manually change the .cfg file to set the L2 InitSize to 512.  Which version of sysbios do you recommend for the C6657?

Thanks,

kim

What about L1P and L1D? A mismatch there is also going to break your app.
Before you update SYS/BIOS, we would have to find what the real problem is. If you get the cache values to match and your app is still not working, the problem could be somewhere else. While running all these tests, you should disable the statements that change the cache in your C code to avoid a third set of the cache config values being possibly mismatched.

The whole initSize structure looks like this:

/* initSize__C */
__FAR__ const CT__ti_sysbios_family_c66_Cache_initSize ti_sysbios_family_c66_Cache_initSize__C = {
ti_sysbios_family_c66_Cache_L1Size_32K, /* l1pSize */
ti_sysbios_family_c66_Cache_L1Size_32K, /* l1dSize */
ti_sysbios_family_c66_Cache_L2Size_0K, /* l2Size */
};

L1D does not match the platform either.  I cannot get cache to work so I have those lines commented out of the .cfg file.  If I try to enable cache (L1D and L2)  in the .cfg file, I make sure they match the platform configuration.  

Thanks,

Kim

These two sets of config parameters have to match for cache to work correctly. If you remove cache statements from the CFG script, and the values don't match, you have to add cache statements back. I think you should have this:

var ti_sysbios_family_c66_Cache = xdc.useModule('ti.sysbios.family.c66.Cache');
ti_sysbios_family_c66_Cache.initSize.l1PSize = ti_sysbios_family_c66_Cache.L1Size_32K;
ti_sysbios_family_c66_Cache.initSize.l1DSize = ti_sysbios_family_c66_Cache.L1Size_16K;
ti_sysbios_family_c66_Cache.initSize.l2Size = ti_sysbios_family_c66_Cache.L2Size_512K;

in your CFG script.

Hi Sasha,

I tried what you suggested but I do not get to main() in my program when I set things up like this.  I am using the HelloWorld TI example, by the way.  The only values that let me get to main() are the default cache settings (L1D=32K, L1P=32K, and L2=0K).  I was using Bios version 6_35_01_29 with XDC version 3.25.0.48.

I then tried a different bios version, with different XDC version.  I am now using 6_35_04_50 bios and xdc version 3.25.03.72.  With these I change the platform L1P, L1D, and L2 cache sizes and then the structure in the 'hello_pe66.c' file looks correct:

/* initSize__C */
__FAR__ const CT__ti_sysbios_family_c66_Cache_initSize ti_sysbios_family_c66_Cache_initSize__C = {
ti_sysbios_family_c66_Cache_L1Size_32K, /* l1pSize */
ti_sysbios_family_c66_Cache_L1Size_16K, /* l1dSize */
ti_sysbios_family_c66_Cache_L2Size_512K, /* l2Size */
};

However, when I run my program, I still do not get to main().  If I change back to the default settings for cache, then I do get to main().  Can you try changing the helloWorld TI example and see if you have any better luck getting cache changes to work?

Thanks,

Kim

Kim,
I built an app with XDCtools 3.25.03.72 and SYS/BIOS 6.35.04.50. I created a custom platform with 32K of cache in L1P, 16K of cache in L1D and 512K of cache in L2. I was seeing a similar problem as you did, and I found that in my case the problem was in the allocation of the .stack section.
In my custom platform, I set cacheMemory to L1DSRAM. The default cache configuration allocates all of L1DSRAM to cache, and that cache was being used before SYS/BIOS had a chance to reconfigure cache. As a result, stack and cache were writing over each other. When I opened my platform in the Platform Wizard and allocated cache to L2RAM, the problem disappeared and I could reach main().
I am not really sure how this was supposed to work, I'll have to ask someone from the SYS/BIOS team who knows more about cache configuration. But, in the meantime you can check if your section .stack is also allocated to L1DSRAM, and what happens when you move it to some other memory. 

Hi Sasha,

The .stack section was being allocated in L2SRAM.

MEMORY CONFIGURATION

name origin length used unused attr fill
---------------------- -------- --------- -------- -------- ---- --------
L2SRAM 00800000 00080000 00012a3e 0006d5c2 RW X
L1DSRAM 00f00000 00004000 00000000 00004000 RW
MSMCSRAM 0c000000 00100000 00000000 00100000 RW X
DDR3 80000000 20000000 00000000 20000000 RW X

SEGMENT ALLOCATION MAP

run origin load origin length init length attrs members
---------- ----------- ---------- ----------- ----- -------
00800000 00800000 0000b6a0 0000b6a0 r-x
00800000 00800000 0000b6a0 0000b6a0 r-x .text
0080b6a0 0080b6a0 00003010 00000000 rw-
0080b6a0 0080b6a0 00003010 00000000 rw- .far
0080e6b0 0080e6b0 000025fe 000025fe r--
0080e6b0 0080e6b0 000025fe 000025fe r-- .const
00810cb0 00810cb0 00001000 00000000 rw-
00810cb0 00810cb0 00001000 00000000 rw- .stack
00811cb0 00811cb0 0000074c 0000062c rw-
00811cb0 00811cb0 0000062c 0000062c rw- .fardata
008122dc 008122dc 00000120 00000000 rw- .cio
00812400 00812400 00000644 00000644 r-x
00812400 00812400 00000200 00000200 r-x .vecs
00812600 00812600 00000444 00000444 r-- .cinit

I then moved the .stack section to DDR3 memory, but I still had no luck getting to main().  If I set L2 memory back to all SRAM (0 cache), then I get to main() in my program.

Any luck with figuring out the issue you saw?  It could be related some how?

Thanks,

Kim

My problem was exactly what I described in my previous post. The section .stack can't be allocated L1DSRAM because all of L1DSRAM is cache by default, and section allocated to that memory will be written over before SYS/BIOS has a chance to reconfigure cache. But, it seems you are not allocating anything to L1DSRAM so that issue probably doesn't apply to your app.
Can you change your platform and set the size of L1P cache to 32K? You are not using that memory anyway, and we can exclude that as a possible source of the problem. Then, try again changing L2 cache from 0K to 512K and back. Also, please check every time that the memory map and the cache init size in the config C file match. One more thing you can try is to allocate everything in your app to DDR3 to see if that changes anything.
Are you still using hello world app? All these variations are working for me with that app.
 

Hi Sasha,

I've tried multiple combinations in past days and today and have verified that the memory map and Cache InitSize match.  I've also tried allocating everything to DDR3.  I never get to a breakpoint that I've set in main() if I use L2 Cache greater than 0.  Can you zip up your hello_world project and send it to me please?  Also include the .gel file you are using to connect to CCS with.

Thanks,

kim

Kim,
I attached my platform 'myBoard6657' and the project. When you unzip the platform, add that directory to the list of the repositories for the project. I am using a simulator because I don;t have a board, so I don't think a GEL file would matter to you. Can you do the same and attach your platform and the project?

7506.myBoard6657.zip
0284.cache6657.zip

Hi Sasha,

Thank you for sending your project.  I tried it out and it did not work.  I then turned off my hardware and waited a while and then tried it again.  I was able to get to main() 2 times.  Then it stopped working.  Sometimes I get to main() but more often I do not.  This seems to be a hardware issue.  Can you get hardware from someone and try your program again?

Thanks,

Kim