STM32U5A5: DCache as "memory"?

[tjaekel]

My question might sound "strange" for HW experts.

My STM32U5A5 MCU has DCache (16KByte). Datasheet says: used when external memory is connected (e.g. NAND/NOR flash, OCTOSPI).
DCache is not used for internal memory (when running from MCU flash or internal SRAM, obvious: not needed, internal SRAM seems to be with same speed as MCU = no DCache needed).

But: 16KByte of memory is provided in chip as DCache:

How could I use this memory without any external memory device used, not connecting external memory?

16KByte, provided as DCache, would give me an option to place the stack region on it (large enough).

So, the "idea" is:

• There is not any external memory connected.
• But I enable DCache and I read/write via the intended base address (for external memory).
• I use the MPU and configure in a way, that this base address is a "write-through" region

I mean:

• if I could configure DCache and MPU so that the DCache is never evicted (not "cleaned", not writing to real external memory)
• and no need to "invalidate" the DCache (nobody has updated the (not-existing) "external memory")
• I could "potentially" use the DCache like a "regular memory"

OK, I understand: when DCache tries to update external memory (for "write-through" or "clean") - the system will potentially hang (because the AXI/AHB bus master will raise an error).

But if I could configure the system in way, that the DCache content is never written neither read back from external memory - it could behave like a regular memory. Just to figure out if MPU config allows a setting for such a "use case".

Dear STM team:
it sounds to me like a "waste" of chip space and memory if DCache is there, but just used with external memories. It would be "cool" if DCache memory becomes available as "regular" memory (with some "config tricks").

"*** idea"? I know, but technically not so difficult to say: "just do read/write on DCache, but never access external memory = do not do any cache policy, not needed to be done, disable transactions to external memory).
Just add a register bit, or a "cache policy" setting in MPU where DCache would never access external memory (and it could work).

[FBL]

Hello @tjaekel 

First let me thank you for all the insights and proposals. Maybe it would be more convincing if we have only DCache1. However,

STM32U5xx product embeds 2 DCACHE 16KBytes each: DCACHE 1 dedicated to external memories and DCACHE 2 placed on GPU2D M0 port and dedicated to improving performance of data traffic to/from external and internal memories. From application perspective, these features allow better performance close to zero wait state data access and lower power consumption when addressing small internal DCache.

Thank you for the clarification @tjaekel 

Indeed, U5A5x does not have GPU2D. Sorry for the confusion, U5A9x does have GPU2D.  

[tjaekel · Accepted solution]

OK - it works!
I can enable DCACHE1 and use as regular memory. I access it via address 0x60000000... after DCache enabled!: I can write and read. COOL.

Just: a DMA to this memory region would not work, just MCU can write and read DCACHE1.
And do not do any cache clean or invalidate operation (it will cause a bus error): even all DCache1 INTs are not enabled and not used - but trying to read/write from/to NON-existing external memory could fail on the bus fabric.

Correcting your response:

• my STM32U5A5 does not have GPU2D (the reference manual is confusing: it tells me there are GPU2D registers, but not which and later it says: GPU2D is just available on other parts (e.g. STM32U599))
• Even I would have a MCU with GPU2D - the MCU cannot make use of DCACHE2:
  This is a Read-DCache for the GPU2D core, on M0 port! MCU cannot write and read from it.
  DCACHE2 is for GPU2D only access-able (to speed up reads from slow external memories, e.g. containing textures)

Anyway, great to know it works to use DCACHE (16KB on U5A5) as "regular memory".
Nothing was needed to setup MPU.

[FBL]

Thank you @tjaekel for teaching me this valuable lesson 😁

Indeed, DCACHE2 is only addressable by GPU2D