TMS570LC4357: Problem with CACHE and DMA

Hello Charles,

I am consulting with one of my associates on your question. I will come back to you when I have some thoughts to share on this. I should have more information tomorrow.

Hello Charles,

Can you change from write-back cache scheme (default per halcogen) to write-through cache. You are reading zeros because it is reading from cache, not from L2. Yes, it is a coherency issue when you use write-back. Or you can declare the buffer non-cacheable.

Just to add -- true even though this is in the direction of  ADC -> L2SRAM because you rely on the ACP for coherency in this direction

and from the TRM:

The Cortex-R5 ACP memory coherency scheme only provides coherency between an external

master connected to the ACP slave port and a CPU with a data cache in the Cortex-R5 group for

memory regions configured as inner cacheable write-through in the CPU’s MPU. It does not

provide coherency for memory regions configured as cacheable write-back.

Hi Chuck,

Thanks for the support.
I tried to configure the buffer as non-cacheable but it did not seemed to work.


I found this post that explained what to do. e2e.ti.com/.../666341

But the part with Halcogen is not much explained. When I configure the
MPU, the resulting code does'nt modify the .cmd file and there is no C code to configure the MPU.



1) For the .cmd I did exactly like in the post.


2) Here is the C code that I did manually:


#pragma SET_DATA_SECTION(".sharedRAM")
AdcBufferMgrOverSampleType adc1BufferMgrG1;
Adc1BufferMgrSingleSampleType adc1BufferMgrG2;

AdcBufferMgrOverSampleType adc2BufferMgrG1;
Adc2BufferMgrSingleSampleType adc2BufferMgrG2;
#pragma SET_DATA_SECTION()


_mpuInit_();
_mpuDisable_();

_mpuSetRegion_(mpuREGION1);
_mpuSetRegionBaseAddress_( 0x08002200 ); //&adc1BufferMgrG1
_mpuSetRegionSizeRegister_( MPU_4_KB );
_mpuSetRegionTypeAndPermission_(MPU_NORMAL_OINC_SHARED, MPU_PRIV_RW_USER_RW_EXEC);
_mpuEnableBackgroundRegion_();

_mpuEnable_();


(Note that we don't use the HalCoGen in our project normally.)

I'm using the compiler v5.2.4 and HalCoGen v03.07.00

Thanks and Regards,
Charles

Hello Charles,

Can you confirm that the variables are located in the address locations/data sections you expect from the pragma definitions/linker updates?

If they are in the right location, we would need to double check the MPU settings to insure the configuration is done correctly. Doing it outside of Halcogen has it's challenges but shouldn't be a major obstacle if you used to it.

Hello Charles,

Were you able to resolve this issue? Please let us know by verifying one of the posted answers using the green verify answer button so that we may close the thread.

Hi Chuck,

Before closing this issue, I have some more questions that are related.

I created a separate memory region with cache disabled for the DMA destination address. It solved my incoherent data results.

Aloso, before that, I had the 2 following errors inthe ESM module:

channel 47 - ACP cache invalidate.
channel 52 - CPU Interconnect Subsystem - Global Error

It make sense that they where caused by the conflict between the DMA and the cache. Now they do not appear anymore.
=> Do you confirm that a conflict between the DMA and the cache would yield these 2 ESM errors ?


Also I saw that in the Errata document there are several issues with the following ESM error source:
channel 52 - CPU Interconnect Subsystem - Global Error

More specifically the (DEVICE#49) :

` CPU Interconnect Subsystem - Global error flag (ESM group 1 channel 52) may be set for untaken
speculative data fetches '

=>How can I prevent untaken speculative fetch ?

=>Does TI recommend masking this error ?


Best Regards,
Charles

Hi Chuck,

Before closing this issue, I have some more related questions.

I created a separate memory region with cache disbled for the DMA destination address. It solved my incoherent data results.
Also, before setting up the MPU, I got 2 following errors in the ESM module:

channel 47 - ACP cache invalidate.
channel 52 - CPU Interconnect Subsystem - Global Error

After the MPU setup I dont get these erros anymore.

=>Do you confirm that a conflict between the DMA and the cache would yield these ESM errors ?


Also I saw that in the ERRATA there is alot of issues concerning :
channel 52 - CPU Interconnect Subsystem - Global Error
More specifically the DEVICE#49
CPU Interconnect Subsystem - Global error flag (ESM group 1 channel 52) may be set for untaken
speculative data fetches.

The work around is :
Enable CPU MPU to block any access (real and speculative) outside the valid memory range.

=>How can I assure no untaken speculative data fetch will arise?
=>Should I disable this error ?

Hello Charles,

Charles Obry said:

After the MPU setup I dont get these erros anymore.

=>Do you confirm that a conflict between the DMA and the cache would yield these ESM errors ?

Yes. This is the reason the errors went away.

Charles Obry said:

The work around is :
Enable CPU MPU to block any access (real and speculative) outside the valid memory range.

=>How can I assure no untaken speculative data fetch will arise?
=>Should I disable this error ?

By using the MPU to block the speculative fetches to memory that isn't valid, you would prevent the errors from occurring. There is still the normal occurrence of untaken speculative fetches but since they are not to invalid memory, the errors will not occur. 

Hi Chuck,

When you say:

By using the MPU to block the speculative fetches to memory that isn't valid, you would prevent the errors from occurring. There is still the normal occurrence of untaken speculative fetches but since they are not to invalid memory, the errors will not occur. 

Is there a default MPU config for the TMS570LC4, that prevent access to invalid memory ?  What do you mean exactly by invalid memory ?

Also, concerning the safety mechanism of the TMS570LC4, do you have statistics about the functionnalities of the IC that are more prone to errors and their rates ?

Is using the cache compare to not using it (as with the LS3) makes a difference ?

Regards

Charles

 

Hi Charles,

I believe Halcogen has a default MPU config in it. What I mean by invalid memory is that there are addresses within the memory space that are unimplemented. Specifically, anything beyond the 4MB range for flash is invalid, in addition to some addresses within peripheral frames that are not used/needed are considered invalid. The default MPU settings may not encompass all of these areas, but you would primarily be interesting in the executable areas anyway to prevent the errors associated with speculative fetches.

There is the detailed information tabs for each of the safety standards that gives the FIT rates for each element (both permanent and transient). Since FIT is failures in time, one could consider this a probability of sorts. Generally speaking, the more transistors in a given feature, the more likely the failure.

I don't believe the use of the cache vs non-use of the cache is an impact to overall safety other than added complexity and transistors that impact the potential for failure.