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: ACP d-cache invalidate problem

Part Number: TMS570LC4357

(CCS 5.5, compiler 5.2.4)

I'm running tough ESM interrupt that report cache errors. This is pretty random throughout my software development once I activate or add some code.

I'm trying to figure out what is going on. Is MPU setting could be the key?

We're working on setting MPU is order to use DMA transfer without interfering with the cache.

I know there are 8 bus masters, one for the DMA, how to configure the bus masters properly? I mean not only for DMA but in order to avoid all of these related problems.

In the user guide, there is this sentence, but that's not talk to me a lot:

« Once user determines the architectural memory partitioning of the IP bus masters on memory system frame according to their application, user should configure the corresponding MPU region for each bus master accordingly. »

Regards.

  • Hello Simon,

    For the last part of your post and the sentence you reference:

    Simon lapointe said:

    In the user guide, there is this sentence, but that's not talk to me a lot:

    « Once user determines the architectural memory partitioning of the IP bus masters on memory system frame according to their application, user should configure the corresponding MPU region for each bus master accordingly. »

    What this is referring to is that once you have determined the valid range of address space that the specific master can access, you can program the specific master's MPU so that it only accesses the memory locations that it is supposed to and has the correct read only or read/write permissions setup. This is not necessarily indicating the CPUs main MPU by by extension it can mean that MPU too.

    Simon lapointe said:
    I'm running tough ESM interrupt that report cache errors. This is pretty random throughout my software development once I activate or add some code.

    Can you provide more information on what types of errors you are seeing?

  • Is there a way to know which bus master interferes ?

    ESM module gives group1 channel 47, which is cache invalidate. I read it as I'm within the ESM isr. I can mask this interruption but then the code isn't running ok.

  • Simon,

    can you try to configure at least the relevant memory range for the peripherals as Write-Through in the CPU MPU and see if this helps.
    Assuming that the issue is arising from the SRAM memory region or the cached version of it.

    Chuck,

    I assume that this ESM signal is connected to the Cortex-R5F eventbus [50] ([50] ACP D-Cache invalidate. - 0x73)?
    However, unfortunately there is no description in the Cortex TRM for this signal, I guess it is related to BHITDIRTYCSm.

    Best Regards,
    Christian
  • Ok.
    But as you configure some memory ranges as Write-Through, it's equivalent to deactivate the cache for the related operations, isn't it? It should then decrease the performance, which is an important point to us.
    For instance we use DCAN. You propose to check which SRAM variables are accesses during CAN operation and place it on specific MPU region with Write-Though setting? Same thing for RTI, MibADC1, etc ?
    It should have some ways to know which peripherals interfere; do you have any hint on this?
    Best Regards.

  • Simon,

    I was a bit vague in my last post, as there are many uncertainties and I aimed on trying to find the root of the issue not on getting the optimal performance in the first place. For sure you are right setting a memory region to Write Through will slow the whole system down, but it is "safer" and simpler to start with this setting than using Write Back.

    Write Through will cause the Cache Controller to almost immediately write memory content which had been modified back to the RAM , this doesn't necessarily has to slow down the CPU. Write Back will cause the Cache Controller to wait with writing until that cache line is about to be replaced with (read from RAM). Write Back therefore might slow down reads from the memory, as the write has to be finished first. However, if the write had already been performed (Write Through) the read could be performed immediately. It is a trade off, as always in life, you get nothing for free ;)

    My suggestion was related to all Bus Masters which are accessing the main SRAM, from your first post I understood that you are using the DMA. I suspect that the DMA is transferring some data between the main SRAM and a peripheral and vice versa. The DCAN however, has its own small RAM which is used for the mailboxes, it accesses the RAM directly (dual port RAM). Some other peripherals like the MibSPI, MibADC, DMA, ENET, N2HET, HTU, FlexRay, ... have local RAMs too. These peripheral RAMs should almost always be configured to Device or Strongly Ordered type memory in the CPU's MPU.

    As a starting point and if you are using the DMA or any of the other Bus Masters (except the CPU) to access the main SRAM, please set the respective SRAM memory region in the CPUs MPU to Write Through or simply the whole SRAM region and see if you still facing the same issue.

    As indicated in my questions to Chuck, the ARM TRM doesn't explain what this error you are facing is about and my aim is to nail down the source of it.

    What I suspect is happening is that the DMA is about to read (most likely) or write to a memory region which is currently in the cache and the cache line is marked as dirty. This would mean that the DMA would read outdated data. Please note that the DMA is directly accessing the main SRAM and not the cache, the cache is only used by the CPU itself. The ACP (Accelerator Coherency Port) and the uSCU (Embedded Micro Snoop Control Unit) are there to catch those situations, handle them and potentially flag an error if they can't resolve the situation.

    Best Regards,
    Christian
  • Christian,

    I spoke about this with Charles and he nor I know for sure which signal on the event bus the ESM error is hooked up to for certain.

    However, the purpose of the ESM flag is to indicate or provide notification and is therefore not really an error unless the action associated with it is unintentional. It is asserted only for Write-through cache scheme. When asserted, it means the cache line is automatically validated when a non-CPU master such as DMA writes to the SRAM. 

      It has to be decided during MPU setup if the CPU and DMA will be using a shared cacheable memory. A shared memory creates data in-coherency issues and this is why d-cache invalidate automatically resolves the coherency if the cache scheme is write-through. D-cache invalidate is not generated in write-back cache scheme.