TMS570LC4357: Rx Issue When SCI used over DMA

Srihari Manthri said:

The size of data missed

Do you mean the transfer size is overwritten?

Can you change the DMA frame size to the number of bytes you are sending: 200bytes, or 200 bytes? 

I did a test between SCI2 and SCI3. SCI3 transfers 200 bytes (frames) per transaction, and transfers totally 100 times. SCI2 receives all the data correctly.

Both SCI2 and SCI use DMA.

Since the memory is configured as write-through with no write allocate, the data is written to main memory (either cache hit, or cache miss). But all the cacheable memory is read-allocate. When CPU reads data from SRAM (or DMA receive buffer), it will read the data present in the cache (on cache hit) and not new data available in the SRAM.

You can perform cache invalidate before reading operation. After cache invalidate, the CPU reads from the cache will then be coherent.

Hi Wang, I believe DMA engine will copy the received UART data into the physical memory space (DMA buffers). User application when accessing if not ensuring cache coherency, can read incorrect data from cached DMA buffers?

Do you suggest if we have to put all DMA buffers into one memory area forced through linker and use MPU to set specific memory protection attributes? Do you think we need to inhibit cache for this region? or we need to keep it enabled? if need to be enabled, then what is the suggested cache policies we need to use?

Could you please provide your feedback on these clarifications.

Thanks,

Kishore

Hello Kishore,

Kishore Bolisetti said:

User application when accessing if not ensuring cache coherency, can read incorrect data from cached DMA buffers?

QJ> Yes, you are correct. 

Kishore Bolisetti said:

Do you suggest if we have to put all DMA buffers into one memory area forced through linker and use MPU to set specific memory protection attributes? Do you think we need to inhibit cache for this region? or we need to keep it enabled? if need to be enabled, then what is the suggested cache policies we need to use?

QJ> I prefer to allocate a shared memory region for DMA buffers. For example

#pragma SET_DATA_SECTION(".sharedRAM")

   uint32 tx_buffer[128];         /* transmit buffer in sys ram */
   uint32 rx_buffer[128]= {0}; /* receive buffer in sys ram */

#pragma SET_DATA_SECTION()

Linker cmd:

MEMORY
{

   ...
  SHAREDRAM (RW) : origin=0x0807A000 length=0x0005000
}

SECTIONS
{

   ...
  .sharedRAM : {} > SHAREDRAM
}

HALCoHen MPU setting:

Select a unused MPU region for SHAREDRAM memory region, configure it as Write-through and write-allocate. 

But DMA write and before CPU read, cache invalidation is still needed.

1. DMA writes data to rx_buffer[]

2. Invalidate the cache lines for rx_buffer[] 

3. CPU reads rx_buffer[]. Since read-allocate policy, a cache line is allocated and rx_buffer[] is copied from SRAM to cache. 

If write-back and write-allocate policy is used, you need to perform a cache clean after CPU write to tx_buffer[] and before DMA transfers.

TMS570LC43x device has a module called uSCU. This unit ensures data coherency between the d-cache and other masters (e.g. DMA and Ethernet) on write-trough regions.

So the step #2 (invalidate cache) is not needed. 

Hi Wang. We have configured the settings as per your guidance. But we have not found the 'Write-through and write-allocate' configuration but we did 'Write-through and no write-allocate' and still saw that the receive bytes were missing. In this case, we have not done explicit flush and invalidate the shared memory area, but it is not making any difference if we do it also.

When we completely disabled the cache for share memory region, we are not seeing any issue. We were still wondering, there is something to do with cache.

You mentioned 'uSCU' will take care making the cache cohering when DMA engine copies the data into RX DMA buffers, if that is the case, why do you think we are still seeing the issue?

Thanks,

Kishore

Hi Kishore,

DMB instructions may be needed to ensure that writes to the SRAM is complete before reading the data.