Infineon AURIX: Accessing variables in cached memory
Possible causes
- The variable is changing, but Real-time Memory access still shows the initial value. In this case, the variable may be cached, which makes Real-time Memory access impossible.
-
The variable value is not updated in the Watch and Memory windows
Note that using any of these solutions may change the behavior of your application.
Possible solutions
Enable Allow cache monitor execution in Hardware | CPU Options | SoC Advanced
This is the preferred solution. With this option enabled, winIDEA will write cached values to mapped memory space. This is only possible when the CPU is stopped.
Re-link the application so that non-cached RAM is used for this variable
You'll be able to see the correct values in the Watch Window.
Disable caching
Use this option if you cannot change the code but need to do some investigations or testing. It disables the data caching per core:
1. Disable ENDINIT protection via an initialization file. SFRs are ENDINIT protected via SCU_WEDCPU<core number>CON0.
2. Perform Debug Download.
3. Use SFR from the CPU group called CPU<core number>_DCON0.
- If you set DCBYP to DCache / DRB Bypass (disabled), the core is disabled. All other caches are continuing if enabled.
- If you set DCBYP back to DCache / DRB enabled, caching is enabled again.
This solution describes an use case if Data cache is enabled and active. It is not meant to enable it from scratch by setting a bit in SFR.
Explanation
The debug interface on TriCore supports only real memory reads via Cerberus, which means that the debugger can only read the real memory, not what is inside the cache. To read the content of cache, the CPU provides a dedicated instruction - CACHEA.W.
On some architectures (i.e. ARM Cortex, NXP/ST Power Architecture) it is possible to insert and execute an instruction. This is called instruction stuffing. However, TriCore debug interface does not support instruction stuffing, therefore CACHEA.W instruction can be executed by CPU only.