- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Assuming that I disable the L1 caches, can I use the cache memory as fast software-controlled scratchpad memory?
According to the technical reference manual, the cache memory is mapped at addresses 0x3000_0000 and 0x3100_0000 (32 KiB each).
With the hardware caching logic disabled, can the software execute regular load and store instructions to these memory locations and expect them to behave normally?
Which addresses were you trying to access?I tried to read/write data from/to cache memory range after enabling AXI-S, but I got abort.
The TMS570LC43x TRM contains the following:
With the "Actual Size" of the Cache Memories specified as 32kB my initial thought that was that the lowest 32kB of each frame would access the Cache Memory.
From an initial poke around the memory map using:
a. The CCS debugger Memory Browser.
b. A TM570LC4357 program halted in _c_int00() before the caches and MPU had been enabled.
c. Using a modified tms570lc43xx.gel in which all of the address from 0x30000000..0x31FFFFFF were marked as RAM, to prevent the CCS debugger from filtering out accesses to parts of the Level 1 Cache Memories frames.
d. In the CCS Registers view manually setting the AXISCEN "Enable AXI Slave Cache RAM Access" bit in the CP15_AUXILLARY_CONTROL register.
From just manually scrolling through the memory map the following addresses are accessible:
The above was a simplistic test which didn't actually confirm which of the above address regions which are accessible are aliases of each other.
Cache RAM access is the ARM Cortex-R5 documentation for how the address bits to cache RAMs are mapped, and will try and create a program to demonstrate using the cache RAMs as "scratchpad memory".
I created a program which read/writes the cache RAMs from a program. To give access to the cache RAMs directly:Cache RAM access is the ARM Cortex-R5 documentation for how the address bits to cache RAMs are mapped, and will try and create a program to demonstrate using the cache RAMs as "scratchpad memory".
a. In the HalCoGen configuration under R5-MPU-PMU -> Cortex-R5 -> General Configuration left the cache as disabled.
b. In the HalGoGen configuration under R5-MPU-PMU -> MPU enabled a region to access the cache RAMs:
c. Used the following function to enable AXI Slave access to the cache RAMs:
static void enable_axi_slave_cache_access (void)
{
uint32_t ACTLR;
const uint32_t AXISCEN = 1 << 24; /* AXI slave cache RAM access enable */
const uint32_t AXISCUEN = 1 << 23; /* AXI slave cache RAM non-privileged access enable */
ACTLR = __MRC (15, 0, 1, 0, 1);
ACTLR |= AXISCEN | AXISCUEN;
__MCR (15, 0, ACTLR, 1, 0, 1);
}A test was made on performing 32-bit write/reads to the following which is a total of 32 KB for the D_cache data RAMs:
When the test program was used to write a test pattern to the above addresses and readback the contents, then with the compiler optimisation level set to off the read back was successful. However, when the compiler optimisation was 2 then the readback failed on some addresses. In the debugger looking in the Memory Browser it looks like some writes to odd words didn't update the data RAM. If single step the optimised program in the debugger, then write in the debugger then data RAM was updated correctly.
I think the there is something which means the cache RAM accessed over the AXI Slave don't support back-to-back accesses, as the interface is supposed to only be used to functionally test the cache RAMs.
Also, the AXI Slave interface to the cache RAMs gives independent access to the ECC so direct access to the data RAM may not update the ECC.
The above is a bit vague, but I don't believe ARM designed the Cortex-R5 caches to be accessed as fast access "scratchpad memory" when the caches are disabled.
