TMS320C6742: Cache configuration on c6742

Richard,

If you use TI-RTOS and configure L1P as SRAM, it will take care of the linker configuration.

All ROM-based bootmodes will use L1P in its default 100% cache mode, so your code will have to change it. Care must be taken to disable the cache before executing any code from L2 or DDR2. It may be advisable to use a secondary bootloader that can be placed in L2, disable the cache and then continue the bootloading process.

Which bootmode do you plan to use?

If you have the space for your uS code in a portion of L1P, setting even a minimum amount of L1P as cache will speed up the code coming from L2 or DDR2.

Regards,
RandyP

Thanks for the secondary bootloader suggestion. Just what I was thinking. I believe my intention is to boot from on chip ROM
I must confess I am puzzled. ROM is not r/w but it is programmable. Is that correct?
If so, then I am thinking I will be programming the secondary bootloader and the application into ROM at manufacturing time. The secondary will be located where the primary expects it and the app will be where the secondary expects it. Beside dealing with the cache problem, I note that the DDR is very unstable. I have composed a snippet to overcome the problems outlined in the errata for this chip, so I have to include this. This makes the secondary mandatory for this chip.
I have opened a second query concerning the DDR problem. When I edit my app.cfg to include this:
var len = Startup.firstFxns.length;
Startup.firstFxns.length++;
Startup.firstFxns[len] = '&_system_pre_init';
pre-init becomes the 0th startup function followed by the stack initiator as the first. Consequently the pre_init which needs a stack goes off into LaLaLand and parks on the reset vector. Go figger.
When I run outside of Bios the RTS simply runs pre_init first and everything works fine.
I know this is a separate thread, but I was wondering if I could get a solution to this problem.

Richard,

I will leave your other thread to the better experts to support that.

No, you do not change the ROM. When the core comes out of reset, it starts running from the ROM. It determines the boot mode and does what is described in the bootloader app note. I do not think of the Direct NOR Flash boot as a ROM-based mode (technically, all of them are ROM-based) since the result is that you just start running out of the NOR Flash.

Which boot mode do you plan to use? There are several. Although I am not a pro at AIS, if you are using one of the AIS modes, then you may be able to simply write to the cache config registers from AIS commands. Read the bootloader app note to figure out how to do that; if it is not possible, I apologize for sending you on a false path.

To take a more holistic approach to this thread, though, our normal recommendation would be to not do any of that. At least, not at first.

Write all of your application and get it running conveniently with L1P/L1D at 100% cache. Depending on the size of your application, it may be good to set L2 to max cache and run everything out of DDR. Use EDMA3 for all data movement, but be sure to use the cache coherency commands as needed for I/O data.

Get your application working functionally in the simple setup. It may surprise you and work fast enough without doing all the hard work on cache configuration tricks. After testing it functionally without optimization (easier to debug), use the compiler optimization to get top performance out of your code. And use EDMA3 instead of long memcpy's.

Regards,
RandyP