STM32H745: shared memory with different content on different cores

[Hansel]

In debug mode, I see the following on CM7:

 

At the same time I see the following on CM4:

 

How is this possible if I have turned cacheability off?

MPU_Region_InitTypeDef MPU_InitStruct;
 
/* Disable MPU */
HAL_MPU_Disable();
 
// Configure SRAM2 as non-cacheable
MPU_InitStruct.Enable = MPU_REGION_ENABLE;
MPU_InitStruct.BaseAddress = 0x30020000; // SRAM2
MPU_InitStruct.Size = MPU_REGION_SIZE_128KB;
MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
MPU_InitStruct.Number = MPU_REGION_NUMBER1;
MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
MPU_InitStruct.SubRegionDisable = 0x00;
MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
HAL_MPU_ConfigRegion(&MPU_InitStruct);
 
/* Enable MPU */
HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);

   

[Hansel]

No one with an idea or a proposal how to debug and fix this problem?

[Tesla DeLorean]

That's how forums work, you're not guaranteed a response..

Which one is correct? What's physically in the memory?

Does cleaning the DCache change things?

Can you do this without the debugger? ie dump stuff directly from the cores, via a terminal or monitor app

Is the MMU working? Unpack the unit configuration. What's in MPU_REGION_NUMBER0 ?

[Hansel]

Thanks for your reply. I physically store on CM7 what's shown in the first snapshot: value 3 in selection. So that one is correct. The one visible on CM4 is not correct. Why would I need to clean the DCache if caching is turned off? I think the MMU is working because the other memory areas for which I have turned off caching are working as expected (I know this because if I use caching, my other code is no more working). MPU_REGION_NUMBER0 says it's 0.

[Hansel]

I tried an SCB_CleanDCache() but that doesn't do the trick either :(

[Hansel]

I couldn't find anything on the internet regarding "Unpack the unit configuration" related to STM32. Would you mind giving me another hint?

[Tesla DeLorean]

You write some code to pull the setting to understand what the processor thinks it's supposed to be doing, and the rules its following. These designs tend to be as simple as possible, it uses the least transistors.

[Hansel]

OK, thanks for that info.

[Hansel]

@Community member​ Many thanks after all. Your questions sent me in the right direction.

I found the bug. I configured four memory areas as strongly ordered. However, I used MPU_REGION_NUMBER1 twice, so the area in question wasn't properly configured.

[Tesla DeLorean]

I don't like how ST does this, they should really have this count auto-increment in the MPU_Config() so you can order and swap.

Also dumping the setting, to see what the processor is doing, vs what you expected, tends to shine a light on things, and catch latent issues which are otherwise missed.

I do this for PLLs and clock trees too.

[Hansel]

How do you dump the settings? Is this something CubeIDE offers or are you talking about a specific way of doing this?

[Piranha]

To potentially improve the performance, read this topic:

https://community.st.com/s/question/0D53W00001Z9K9TSAV/maintaining-cpu-data-cache-coherence-for-dma-buffers

And, related to memory types, this one:

https://community.st.com/s/question/0D50X0000C4Nk4GSQS/bug-missing-compiler-and-cpu-memory-barriers