Problems running NDK 2.20 from external DDR2 memory

I suppose it would help to provide specifics about my platform!  I'm using a custom board running a C6455, but it is based very closely off the DSK6455.  I rebuilt the hal_eth driver for use with the 6455 as well as the hal_userled.  I'm running CCSv5.1.1.00031.  

I have plenty of DDR2 memory (512 MB) to hold the simple application I'm running.  The DDR2 memory is currently being configured through use of a GEL file (i.e. that which is supplied by Spectrum Digital, although modified to have the DDR2 at the right memory address).  

Hi Derek,

I'm not sure how the DDR2 would be causing you to see a If you're getting a "NO PHY CONNECTED". It shows that the PHY wasn't properly initialized.

Are you able to access MDIO registers from the memory window or register view? Have you changed anything in the csl_mdio.c or csl_mdio.h?

Can you run the NDK from the DDR2 on the DSK6455 without modifying the driver?

I found I wasn't able to run the NDK without first creating a version of the hal_eth library which was compiled with the _INCLUDE_NIMU_CODE define and which did some initialization that is performed in a few of the Spectrum Digital provided files.  Beyond that, I haven't tried to run my application on the DSK because there are differences in where things are memory mapped on my custom board.

For now, I have enabled 32k of L2 cache which seems to allow the NDK to properly run.  I am curious, however, as to why enabling 32k of L1 cache does not seem to help (in other words, the cache I enable has to be L2).

Hi Derek,

Can you compare the working version with the non-working version?

You're saying that the NDK works when it's run from L2 RAM. Can you see if there are any differences in the MDIO_timerTick()?

For example, can you step through the driver to see if the hMDIO handle is contains a valid phyAddr member variable? If you don't have a valid handle or a bad phyAddr, then MDIO_timerTick() will fail. It's hard to pin-point the problem from here.

Perhaps, the driver has some hard coded memory addresses, which could cause you a problem. Did you take a look at the NDK 2.00, which has a driver for the DSK6455?

Hi Tom, thanks for your response.  I'm not sure how to step through the driver code when I'm linking it in as an external library.

And I suspect that the problem is not related to hard-coded memory addresses due to the fact that I'm able to successfully run out of DDR2 if I specify the usage of 32 kB of L2 cache.  I did look at the hal_eth driver for the DSK6455 from NDK2.0 and used it as a basis for creating the hal_eth driver I am using.

For now, I will run using L2 cache, as this seems to be working for me.

Can you shed some light for me on why enabling L1 cache does not work but enabling L2 cache does?

Hi Derek,

When you say that you're disabling L2/L1 cache, how are you doing that? How do you know it's turned off/on?

Did you create a new platform using the platform wizard for your board? I think you need to use a different platform that reflects your cache settings. See this tutorial on how to use the platform wizard.

Yes, I am using a custom platform package where I have enabled 32 kB of L2 cache and no cache in L1.

Hi Derek,

Are you doing any MAR bit configuration?  Can you please attach your *.cfg file to this post?

Also, how are you doing cache configuration?  Are you using the *.cfg file?  Or are you doing this at runtime with Cache API calls?  If so, please post the API calls.

Thanks,

Steve

Hi Steven, thank you.  I am not doing any explicit cache configuration.  I am simply "enabling" it in the RTSC platform configuration, as shown in the image .  

The cfg file I am using is directly from the NDK example, basically without modification.

I am doing MAR bit configuration, but only zeroing them out.  Specifically:

volatile uint32_t *MARs = (volatile uint32_t *)0x01848000;

for (i=176; i < 184; i++) {
printf("MAR%d = %08x\n", i, *(MARs+i));
*(MARs+i) = 0;
}

Another question I have regarding cache is: how do I specify which memory locations are used for the L2 cache?  In other words, I'd like to know where my application resides in memory.

I bet you're right, and it has something to do with setting the cacheability flags of DDR.  I haven't had a chance to try yet, so I didn't want to respond preemptively.  I will get back to this.  I appreciate your help and your continued support!

Thank you very much for your help.  The answers to these questions is helping our team immensely.  I have just a couple more which I think I unclearly stated previously.

Steven Connell said:

I'd like to know where my application resides in memory.

You should have a generated *.map file from your project build. It should be in a sub directory "Debug" or "Release" of your project.

[/quote]

I suppose I wasn't very clear what I meant by that statement.  I'm creating a 2nd-level bootloader which will be stored in flash and run on power-up.  The purpose of the bootloader is to accept an application's code segments sent down over UDP from an upper layer.  For now, this application resides entirely in L2 memory.  The code segments are placed at their respective locations, and upon completion, the bootloader will branch to that application's entry point (_c_int00).  

Since I'm enabling 32 kB of L2 cache for the bootloader, I need to ensure that the memory locations which are allocated for the bootloader cache do not reside within a memory location used by the application (otherwise, I would overwrite the bootloader cache when I write the respective application memory segment).  Thus, knowing where in memory the cache physically resides would be helpful.  For now, I've made the size of the IRAM memory segment 32 kB and put it at the end of L2.  Since the application (to be transferred) starts at the beginning of L2 and is smaller than (L2 - 32 kB), this seems to be working for me.  This leads me to believe the linker is reserving space in the IRAM segment for cache, but this doesn't seem right.

So I guess a better way to ask my questions is:

- Does L2 cache always end up in the memory segment IRAM (I suspect no since I could rename that section to anything)?

- Can I control which memory locations are used for cache?

I've read the chapter on L2 Memory and Cache in the megamodule reference guide (spru871j), but it is not explicit about where cached memory resides.  Did I misread this chapter?

Regarding running my NDK example out of external DDR memory:

By specifying the cacheability of DDR using the MAR registers, I've been able to get my application to run out of L1 cache, but not without cache completely.  In doing so, the run speed of my bootloader (i.e. the time it takes to transfer the application from the upper layer) doubled.  For us, this is an unacceptable hit, and I suspect it would only be exacerbated by using no cache at all.  

Regarding the example you provided:

I was finally able to compile/link when I included my own hal_eth.lib and hal_userled.lib instead of the pre-built library you provided (as the endianness was different than on my device).  I've been able to successfully run (obtain an IP address and ping) the application with all cache configurations (controlled through bcacheSize in nonCopyTCH.h).  However, I'm curious how to run the benchmark tests I see referred to throughout the application.  

Thanks again!

Hi Derek,

I've asked for some help from our local cache expert...

Derek Wilson said:

Does L2 cache always end up in the memory segment IRAM (I suspect no since I could rename that section to anything)?

yes, in the sense that IRAM is defined for L2 memory.  If you specify the L2 Cache Size in the platform, it should adjust the IRAM size accordingly.

Derek Wilson said:

Can I control which memory locations are used for cache?

No, you cannot control which locations are cached.  Its always the high end of L2 RAM.  This is specified in the data sheets or Cache document.

Derek Wilson said:

I've read the chapter on L2 Memory and Cache in the megamodule reference guide (spru871j), but it is not explicit about where cached memory resides.  Did I misread this chapter?

It should be there, but he thinks maybe the diagram isn't in all of the docs (?).  In any case, please look at page 27 in the following one:

http://www.ti.com/lit/ug/spru862b/spru862b.pdf

Steve

Thank you for your help.  This was the exact document I was looking for.