C674x Internal memory question

L1P is not designed for use as data space, only for code/program space.

Please see the C674x DSP Megamodule Reference Guide for the DSP you are using, to find more information on the use and control of the cache/SRAM configurations. The device datasheet will also include important information on the choices you can make.

Which device are you using? That can make a difference, in some cases.

Regards,
RandyP

I am using the C6747 at the moment and I am looking at moving to the C6748.

I have been reading through the datasheets and appropriate guides but it would be better if there was some example code available.

I believe that I have managed to read and write to L1D by switching off the cache and allocating the area as RAM.

I cannot seem to do the same to the L1P area.  Is there any example code available which will show me how to read and write to the L1P area ?   If it is not designed for use as data space is it possible to allocated space there in the linker command file ?

I prefer to stay as practical as possible in my discussions on the forum.

Put your program code in L1P, including all non-data initialized sections. That is what it is available for, by switching of that cache. You switch it off about the same way you did the L1D cache.

Initialize all variable at load time instead of run time, if that works for your application. This will reduce some of the memory space required.

How much more space do you need, and for what purpose?

Regards,
RandyP

How can I put code into L1P ?  I have switched off the cache associated with it but I cannot write to it - I think it is protected. 

I tried using it exactly as I am using L1D.

I am using L1D to store some large filter buffers which get filled at run-time.

I am currently using most of L2 for code and data but it's nearly full - I just need more on-board space!

How do you put code into L2?

The CCS loader can write code to it and the EDMA3 can write to it. The Bootloader can write to it.

You cannot use L1P as data space. The CPU cannot write to it.

Regards,
RandyP

I have L2 defined in the linker script file.

I have tried to do the same for L1P and located some code in their.

It doesn't seem to run (when I use L1P).  It runs perfectly well when just using L2.

I am booting the dsp via the UHPI if that makes any difference.

Do you have any more suggestions ?

Use CCS to load and test your program. You need the visibility and known good operation to be able to debug your problem. Be sure to change the settings in the GEL file to turn off L1P cache.

Unfortunately it's impossible to load my program with CCS - the only way is via UHPI (from a master processor).  Or I could boot via UART.

I am not using a GEL file either.

Why is it impossible to use CCS? That greatly increases the difficulty in debugging problems for you locally, and makes it almost impossible to help you remotely. Please keep this in mind for your next board spin.

L1P is not protected. If you have it configured as SRAM then you can write to it and execute from it.

What address are you using for L1P in your linker command file?

When, exactly, do you turn off the L1P cache?

Load a test program into L2 that just does an IDLE spin. Once it is running, read the L1PCFG register from UHPI to confirm that L1P is still 0k cache / 32k SRAM.

Load a test program into L2 that uses EDMA3 to copy some test code into L1P, then use EDMA3 to read it back and compare it. Also use UHPI to compare it.

Use UHPI to load into L1P then read it back to see if the data was written correctly.

Regards,
RandyP

Is there any reason not to the use 128KB on On Chip Memory?

The hardware platform has a host processor and a C6742 (which doesn't have 128KB on board).

The C6742 does not have a JTAG interface connected due to insufficient space on the board.

So I have to debug it through the UHPI and/or the UART.

I'll try your suggestions and see where it leads me.  All I want to do is put some code into L1P - how hard can it be ?

Okay. You had only mentioned C6747 and C6748 before. The C6742 only has 64KB L2. Moving up to a C6746 would get you 256KB L2. Are you limiting yourself to 64KB of the 256KB memory on the C6747 dev board? If you manage to use L1 memory as RAM, please post, useful to know in a extreme crunch.

I am not using an evaluation board.  We have designed our own board using a master processor and C6742.  It's working well so far.

We having chosen the C6742 because it suits our purposes - however I can see that the 64KB will be a limiting factor sooner or later.

I believe I have managed to use L1D as RAM (32KB) and I would like to also use L1P (either as data RAM or code space).

I've not done this before, but I can imagine that there could easily be some issues:

1. The L1P and L1D values coming out of reset have them both enabled as 100% cache.  It seems to me you should not be loading code/data into that memory until the CPU has configured them as SRAM.
2. Make sure you're using the global address (e.g. 0x11E00000, 0x11F00000) from the HPI since the other addresses (0x00E00000, 0x00F00000) are local to the CPU.

So I would expect the procedure would need to be something along these lines:

1. HPI writes some kind of stage1 CPU code into the L2 RAM.
2. HPI wakes up CPU which executes the stage 1 code from L2.  This code will reconfigure L1P/L1D as SRAM.  It would then alert the HPI when it was complete, either through interrupt or by writing to a predetermined location.  CPU then spins waiting for message back from HPI.
3. Now that the HPI knows the L1P/L1D is configured as SRAM, it can safely write to it.
4. Once done writing to L1P/L1D it notifies CPU (e.g. through interrupt or predetermined memory location) that it can move forward with execution.
5. CPU executes "as usual", i.e. now all the code data has been loaded into the expected location.

Good luck.  :)

Brad's suggestion to use a stage1 CPU code (to get the L1 memories configured) could also be extended to do all of the _c_int00 initialization prior to your main() function. Since any data space initialization requires a .cinit or .pinit section, you could put all of that in the stage1, then stage2 could just start at main() and save all of the initialization program and data space needed by those sections that are only used once after reset.

This would require a lot of new techniques to get the two stages generated, and that will be a lot of work. So it would just come down to how expensive all that memory space is versus how much can be saved by going to these great lengths.

Regards,
RandyP