Problem with SDRAM and Cache

Mary Frantz

Other Parts Discussed in Thread: OMAPL138

We are developing a custom board using the C6746.

I have had the NDK working for some time now, though when streaming data we are losing some blocks of data. I have seen references to L2 cache being an issue. Our board has SDRAM and not DDR. The default setup used in the NDK examples that I copied have L2 set to all cache and the MAR192-223 set to 0xffffffff. I changed the MAR128 bit to 1 and the MAR64 and MAR65 bits to 1 to enable caching of the SDRAM. After doing this the host PC cannot make a socket connection to the DSP board server. I can't ping either. Have I set up this correctly? Attached is my tcf file. The usual messages appear in the console window at boot up indicating that the EMAC is initialized and the appropriate (hard coded) IP address has been added, and the PHY link is good (100 Mbit/s).

I am using NDK 2.20.03.24, NSP 1.00.00.09, BIOS 5.41.10.36, EDMA LLD 01.11.02.05, and CCS 4.2

I have corrected the lost blocks of data issue by buffering up more data before calling send() on the socket. But I would like to know why caching the SDRAM causes the network operations to fail. I would like to be able to enable caching for the SDRAM. I thought I read in one of the documents that the EDMA handles cache coherence automatically. I would expect the NDK stack to handle it if the DMA doesn't. If I leave caching enabled for L3_CBA_RAM (MAR128) but disable caching for SDRAM (MAR64, MAR65) it works fine.

Mary

over 14 years ago

0 Alan DeMars over 13 years ago

TI__Mastermind 30830 points

Mary,

Sorry for the late response. Everyone's been out on Holiday and vacation.

My understanding is that the EDMA handles coherency between L1 and L2 caches but NOT with external memory.

NDK does NOT manage cache coherency at all. So EDMA transferred packets residing in SDRAM that are manipulated manually by the NDK or user are vulnerable to cache incoherency problems.

So it seems to me that leaving the SDRAM non-cacheable is correct.

Alan

0 Steve Kreyer over 13 years ago in reply to Alan DeMars

Intellectual 520 points

Alan,

we had the same issue currently. We found out that it is also possible to use the NDK / NSP without disabling the cache. In the NSP driver in the file etherdriver.c there's a define called EXTMEM. This specifies the base address of your external memory (in case of DDR it's 0x8000...). The NSP code inside etherdriver.c only issues a cache clean command if the buffer address fits inside the base address specified in EXTMEM (the buffer address is bitwise &-masked with this macro and only if this operation evaluates to true the cache is cleaned). So if your external SDRAM-memory e.g. is located at base address 0x40000... this macro has to be adapted to that address, the driver needs to get recompiled and then it should run without disabling the whole cache. In our case it worked.

Kind Regards,

Steve

0 Mary Frantz over 13 years ago in reply to Steve Kreyer

Intellectual 580 points

Thanks! Your solution worked.

For others' sake here are the steps I followed:

Read the release notes provided with the NSP to learn how to rebuild the NSP driver.

Copy the whole NSP folder to a new directory, and give it a new name (as described in the release notes).

Modify etherdriver.c, (located at NSP_1_00_00/packages/ti/drv/omapl138/) changing EXTMEM to 0x4000000 for SDRAM.

Rebuild as described in the release notes.

Make a new environment variable (i.e. "CUSTOM_NSP_INSTALL_DIR") and set it to this new NSP directory.

In the project, open the Properties wizard. Under C/C++ Build --> C6000 LInker --> File Search Path change the search path for the NSP drivers from

"${NSP_INSTALL_DIR}/packages/ti/drv/omapl138/lib/release/ti.drv.omapl138.a674"

"${CUSTOM_NSP_INSTALL_DIR}/packages/ti/drv/omapl138/lib/release/ti.drv.omapl138.a674"

Set the MAR64 and MAR65 bits to 1 in the project .cfg file.

Processors

Processors forum

Problem with SDRAM and Cache