• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 1175 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LC4357: TMS570LC4357: DMA and caching modes.

Nick_
Prodigy 20 points
Part Number: TMS570LC4357

I have 2 questions about DMA and caching related to using DMA on SPI, though they are not SPI-specific:

1) Is it valid to DMA from/to memory that is marked as not shared, but is write-through cached? If so is there ever a time to prefer using shared (non-cached) memory with DMA vs write-through cached memory with DMA? The DMA SPI example and this article (https://e2e.ti.com/group/launchyourdesign/m/boosterpackcontest/666341) recommend using a shared (uncached) memory region for DMA buffers. However it is my understanding that the TMS570's Accelerator Coherency Port implementation will keep the cache synced when DMA writes to memory marked as write-through. "Transactions are received on the ACP-S slave port, and transmitted on the memory system via the ACP-M master port. The ACP automatically invalidates the appropriate Level 1 data-cache lines at the appropriate time, allowing software maintenance free cache coherency for data in write-through cache regions, as well as non-cached."

2) Is a DMB needed prior to enabling DMA or is the write to the device type memory (enabling of DMA) enough to ensure that memory will be viewed coherently by DMA? It is my understanding that a write to device type memory will drain all pending write buffers first.

Thanks in advance!

  • 0
    Prodigy 20 points
    Slight inaccuracy in my original post: the cited example recommends a separate region of write-through cached memory for DMA buffers (not marked as shared, though it is called "SHARED" in the example).
  • 0
    Prodigy 250 points
    1) "Is it valid to DMA from/to memory that is marked as not shared, but is write-through cached?" -- Let's say CPU writes to a RAM buffer then kicks off DMA to Tx. Buffer is write-through cached. The write-through operation needs to be complete before DMA is kicked off, so it's necessary to issue DMB instruction prior to kicking off DMA. In the other direction, DMA is kicked off and copies to a buffer, then DMA finishes. I think ACP will take care of you.

    1a) "If so is there ever a time to prefer using shared (non-cached) memory with DMA vs write-through cached memory with DMA?" -- I would guess either would be OK, it might be preferred to use write-through caching to speed read performance, depending on how the memory will be used by CPU. TI folks, does this sound right?

    2) "Is a DMB needed prior to enabling DMA or is the write to the device type memory (enabling of DMA) enough to ensure that memory will be viewed coherently by DMA?" -- This doc suggests issuing DMB -- infocenter.arm.com/.../index.jsp but I'm not sure about this characteristic of "device type memory" that you mention. Can you link to more info?
  • 0
    TI__Mastermind 49120 points
    Hi Nick,

    The concept of a "shared" memory for the Cortex R4/5 architecture has nothing to do with a memory that is accessed by multiple bus masters. It is useful in case there are multiple CPUs that have access to the same memory region, which is not the case for the LC4357 devices. So in effect the shared/non-shared configuration has no effect.

    Answers to your specific questions:
    1) The ACP provides cache coherency for data cache defined as write-through.
    2) A DMB instruction is not required after writes to device-type or strongly-ordered memory. It can be used to ensure that the write to the device-type memory completes before the CPU proceeds with the next instruction. Successive accesses to device-type memories ensures that all previous accesses are completed. So you can also read back from the register that you just wrote to just so that you are assured that the write is completed and not pending in the CPU's buffer.

    Regards,
    Sunil