RM57L843: Non cacheable memory region

Hi Ravi Teja,

Can you please refer below FAQ to understand different attributes of MPU:

(+) [FAQ] TMS570LC4357: What are the differences among the memory attributes, memory types and cache policy in MPU settings? - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

--
Thanks & regards,
Jagadish.

Hi Jagadish,

I am confused now. In the thread you shared, it says tye following.

———————-
What does non-cacheable mean?

Each read and write is performed on the main memory, doesn’t go through the cache.
———————

Whereas, in a previous thread, you mentioned that setting memory region as non cacheable for emac buffers will have no effect and instead you had suggested marking it write through. Can you please clarify? This is what you had me tioned in the following thread

————————

I don't think NORMAL_OINC_SHARED will prevent from caching. We should need to configure the corresponding memory into write through(WT).

————————

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1380009/rm57l843-cannot-start-emac-transmission/5281627#5281627

Ravi

Hi Ravi,

My apologies,

Non-cacheable should also solve the issue.

Can you try this NORMAL_OINC_SHARED setting for both RAM and descriptors memories that we discussed in old thread and verify the result?

--
Thanks & regards,
Jagadish.

Hi Jagadish,

i did try that NORMAL_OINC_SHARED for both memory and descriptors and it still doesnt work for some reason

Ravi

Hi Ravi Teja,

I created one simple example and tested this MPU configuration and i didn't see the issue.

Actually, i created one DMA memory to memory transfer example, here DMA transferring data from TX_DATA to the RX_DATA:

1. First i tested with disabled cache and Write Back Write Allocated configuration:

And here are the test results:

As we are disabling the cache, we can be able to receive the data from TX_DATA to the RX_DATA without any issues.

2. Now i tested with enabling the cache and Write Back Write Allocated configuration:

And here are the test results:

Even though i received the interrupt, due to cache enabling my RX_DATA buffer was showing empty. This is because the DMA transfer taken place in the background and CPU not aware of that and maybe it is showing in the cache data of all 0's.

3. Now i tested with enabling the cache and NC(Non-Cacheable):

Here are the results for above configuration:

Now again i am able to see both interrupt and data transfer to the RX_DATA. As we set the Non-Cacheable option, the CPU always trying to show the data in the main memory instead of cache.

I am attaching my code for your reference; can you please verify it and test it on your end:

DMA_Memory_to_Memory_Transfer_RM57.zip

--
Thanks & regards,
Jagadish.

Hi Jagadish,

Apologies for late response. I tried the settings you suggested with EMAC. I first created an RM57 FreeRTOS source from Halcogen. I then 

Hi Jagadish,

Any update on this?

Ravi

Hi Ravi Teja,

I didn't get a chance to work on it again, due to other issues.

I am working on it now and will try to provide my update as soon as possible.

Before that i want a small clarification from you:

Ravi Teja Darbha said:

I am suspecting that the freertos code generated by halcogen is messing with the MPU settings from the halcogen. I can't seem to find it. Can you please take a look?

What about write-through setting (NORMAL_OIWTNOWA_SHARED) that we discussed in below thread, is this setting making it work?

(+) RM57L843: Cannot start EMAC transmission - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

--
Thanks & regards,
Jagadish.

NORMAL_OIWTNOWA_SHARED doesn't work in freertos task. It only works in baremetal environment.

I think I found the culprit. In os_port.c, vPortStoreTaskMPUSettings configures entire RAM as NORMAL_OIWBWA_NONSHARED in the higher MPU regions (thereby higher priority). This overrides any MPU settings we make in Halcogen. I honestly, don't under the whole point of configuring the same RAM region as NORMAL_OIWBWA_NONSHARED during every FreeRTOS task creation when we can just configuration it once during initialization when xRegions is defined as NULL. Do you have any comments on this?

I am referring to this piece of code.

if( xRegions == NULL )
{
/* USER CODE BEGIN (6) */
/* USER CODE END */
/* No MPU regions are specified so allow access to all of the RAM. */
xMPUSettings->xRegion[0].ulRegionBaseAddress = 0x08000000;
xMPUSettings->xRegion[0].ulRegionSize = portMPU_SIZE_512KB | portMPU_REGION_ENABLE;
xMPUSettings->xRegion[0].ulRegionAttribute = portMPU_PRIV_RW_USER_RW_EXEC | portMPU_NORMAL_OIWBWA_NONSHARED;

/* Re-instate the privileged only RAM region as xRegion[ 0 ] will have
just removed the privileged only parameters. */
xMPUSettings->xRegion[1].ulRegionBaseAddress = 0x08000000;
xMPUSettings->xRegion[1].ulRegionSize = portMPU_SIZE_4KB | portMPU_REGION_ENABLE;
xMPUSettings->xRegion[1].ulRegionAttribute = portMPU_PRIV_RW_USER_NA_NOEXEC | portMPU_NORMAL_OIWBWA_NONSHARED;

/* USER CODE BEGIN (7) */
/* USER CODE END */
/* Invalidate all other regions. */
for( ul = 2; ul <= portNUM_CONFIGURABLE_REGIONS; ul++ )
{
xMPUSettings->xRegion[ ul ].ulRegionBaseAddress = 0x00000000UL;
xMPUSettings->xRegion[ ul ].ulRegionSize = 0UL;
xMPUSettings->xRegion[ ul ].ulRegionAttribute = 0UL;
}
/* USER CODE BEGIN (8) */
/* USER CODE END */

NORMAL_OIWTNOWA_SHARED doesn't work in freertos task. It only works in baremetal environment.

I think I found the culprit. In os_port.c, vPortStoreTaskMPUSettings configures entire RAM as NORMAL_OIWBWA_NONSHARED in the higher MPU regions (thereby higher priority). This overrides any MPU settings we make in Halcogen. I honestly, don't understand why we are configuring the same RAM region (when xRegions is defined as NULL) as NORMAL_OIWBWA_NONSHARED during every FreeRTOS task creation when we can just configure it once during initialization. Do you have any comments on this?

I am referring to this piece of code.

if( xRegions == NULL )
{
/* USER CODE BEGIN (6) */
/* USER CODE END */
/* No MPU regions are specified so allow access to all of the RAM. */
xMPUSettings->xRegion[0].ulRegionBaseAddress = 0x08000000;
xMPUSettings->xRegion[0].ulRegionSize = portMPU_SIZE_512KB | portMPU_REGION_ENABLE;
xMPUSettings->xRegion[0].ulRegionAttribute = portMPU_PRIV_RW_USER_RW_EXEC | portMPU_NORMAL_OIWBWA_NONSHARED;

/* Re-instate the privileged only RAM region as xRegion[ 0 ] will have
just removed the privileged only parameters. */
xMPUSettings->xRegion[1].ulRegionBaseAddress = 0x08000000;
xMPUSettings->xRegion[1].ulRegionSize = portMPU_SIZE_4KB | portMPU_REGION_ENABLE;
xMPUSettings->xRegion[1].ulRegionAttribute = portMPU_PRIV_RW_USER_NA_NOEXEC | portMPU_NORMAL_OIWBWA_NONSHARED;

/* USER CODE BEGIN (7) */
/* USER CODE END */
/* Invalidate all other regions. */
for( ul = 2; ul <= portNUM_CONFIGURABLE_REGIONS; ul++ )
{
xMPUSettings->xRegion[ ul ].ulRegionBaseAddress = 0x00000000UL;
xMPUSettings->xRegion[ ul ].ulRegionSize = 0UL;
xMPUSettings->xRegion[ ul ].ulRegionAttribute = 0UL;
}
/* USER CODE BEGIN (8) */
/* USER CODE END */

Hi Ravi Teja,

First of all, my apologies for the delay in late response, i was stuck with other issues in this mean time.

Ravi Teja Darbha said:

I think I found the culprit. In os_port.c, vPortStoreTaskMPUSettings configures entire RAM as NORMAL_OIWBWA_NONSHARED in the higher MPU regions (thereby higher priority). This overrides any MPU settings we make in Halcogen.

Good to hear that you found the root cause for the issue.

Ravi Teja Darbha said:

I honestly, don't understand why we are configuring the same RAM region (when xRegions is defined as NULL) as NORMAL_OIWBWA_NONSHARED during every FreeRTOS task creation when we can just configure it once during initialization. Do you have any comments on this?

Honestly i don't have any idea why they configured NORMAL_OIWBWA_NONSHARED for FreeRTOS. I even checked old threads and i don't see any information related to it.

I am suspecting maybe it is just because they try to use the cache effectively. However, as we discussed this configuration can create the issue that we discussed; the main memory may not contain latest data all the time. So, my suggestion would be better to go with the Non-cacheable configuration as we saw this (NORMAL_OIWBWA_NONSHARED) creating issues at your program.

--
Thanks & regards,
Jagadish.