OMAP L138 Cache_inv mDDR issue with SYS/BIOS 6.40

Pirow Engelbrecht

Hello,

I'm currently DMA'ing in data from an SPI interface into L2 (ping-pong buffering). Because of size limitations of L2, an additional DMA transfer is used to DMA data out to a large mDDR-based circular buffer. Upon completion of the DMA transfer out to mDDR, the cache is invalidated for that specific block that has been transferred. The user application can then grab the next block from mDDR when it is ready to process using a straight up memcpy.

My issue is with the cache_inv for mDDR-base blocks. I call cache_inv as follows:

Cache_inv(&rxBuf[rxIndex],BLOCK_SIZE_IN_BYTES,Cache_Type_ALLD,true);

By calling the Cache_inv function with true, I expect the Cache_inv to block until the cache has been invalidated for that particular address range. In fact, it almost immediately returns (<1us delay), and examining the large mDDR buffer using an emulator I can see old data in the buffer, which means that the cache_inv call is not finished when returning.

For now I have a workaround - I basically DMA a block back into L2 working memory when needed by the application. This works because of L2 cache memory snooping on DMA transfers into L2.

Has anyone experienced similar issues? Am I using the Cache API wrong?

I've checked the Cache MMR bits (we have mDDR set as cached). I'm using SYS/BIOS 6.40.

Thanks

over 10 years ago

Titusrathinaraj Stalin over 10 years ago

TI__Guru** 116100 points

Hi,
Please refer to the following TI wiki pages where discussed general info and cache issues.
processors.wiki.ti.com/.../Cache_Management
processors.wiki.ti.com/.../Enabling_64x%2B_Cache

Pirow Engelbrecht over 10 years ago in reply to Titusrathinaraj Stalin

Intellectual 530 points

Hello Titus,

I am already aware of those. Thanks. The problem is that the SYS/BIOS cache_inv does not seem to finish, even though it is called with a true in the wait argument.

Any other things I need to look at?

Titusrathinaraj Stalin over 10 years ago in reply to Pirow Engelbrecht

TI__Guru** 116100 points

Hi Pirow,
I moved your post to TI-RTOS forum, there you would get support from our SYS/BIOS experts.

Steven Connell over 10 years ago

TI__Mastermind 45025 points

What are the values of the following arguments you are passing?

- rxIndex
- BLOCK_SIZE_IN_BYTES
- what is the size of rxBuf[]? Maybe you could show me the declaration of this buffer.

Steve

Pirow Engelbrecht over 10 years ago in reply to Steven Connell

Intellectual 530 points

Hi Steve,

rxIndex is an index into a circular buffer. It is increment every time on receiving a block (420 tRxcData samples):

rxIndex += RX_DATA_SIZE;

It is wrapped around once reaching the end of the buffer.

For rxBuf:

typedef struct _tRXcData
{
int16_t chan1;
int16_t chan2;
} tRXcData;

#define RX_DATA_SIZE 420

#define RX_LARGE_BUF_SIZE 1500

#pragma DATA_ALIGN (8); // 64-bit aligned (C++)
#pragma DATA_SECTION(".RX_SAMPLE_BUFFER");
tRxcData rxBuf[RX_LARGE_BUF_SIZE*RX_DATA_SIZE];

#define BLOCK_SIZE_IN_BYTES (sizeof(tRxcData)*RX_DATA_SIZE)

Thanks

Steven Connell over 10 years ago in reply to Pirow Engelbrecht

TI__Mastermind 45025 points

Which core are you running on? The ARM9 or the C674x DSP?

(the implementation of Cache_inv() is different depending on the core family)

Steve

Pirow Engelbrecht over 10 years ago in reply to Steven Connell

Intellectual 530 points

Hi Steve,

I'm running on the DSP core.

Thanks

Steven Connell over 10 years ago in reply to Pirow Engelbrecht

TI__Mastermind 45025 points

Ok, thanks.

Can you please attach your *.map file and *.cfg file?

I'd like to check your MAR settings.

Steve

Pirow Engelbrecht over 9 years ago in reply to Steven Connell

Intellectual 530 points

Hi Steve,

I've found this in the OMAP L138 manual:
From the mDDR manual:
Possible Race Condition
A race condition may exist when certain masters write data to the DDR2/mDDR memory controller. For
example, if master A passes a software message via a buffer in DDR2/mDDR memory and does not wait
for indication that the write completes, when master B attempts to read the software message it may read
stale data and therefore receive an incorrect message. In order to confirm that a write from master A has
landed before a read from master B is performed, master A must wait for the write completion status from
the DDR2/mDDR memory controller before indicating to master B that the data is ready to be read. If
master A does not wait for indication that a write is complete, it must perform the following workaround:
1. Perform the required write.
2. Perform a dummy write to the DDR2/mDDR memory controller SDRAM status register.
3. Perform a dummy read to the DDR2/mDDR memory controller SDRAM status register.
4. Indicate to master B that the data is ready to be read after completion of the read in step 3. The
completion of the read in step 3 ensures that the previous write was done.
The EDMA peripheral does not need to implement the above workaround. The above workaround is
required for all other peripherals. See your device-specific data manual for more information.

I believe that to perform a Cache_inv correctly, the DSP should perform actions 2 and 3 before starting a DMA transfer. I'll test in the morning.

Thanks

Processors

Processors forum

OMAP L138 Cache_inv mDDR issue with SYS/BIOS 6.40