Locked L2 cache (Pl310) Write issue through JTAG- Zynq 7000

We are using a Zynq-7000 SoC, and we are trying to do read and write to a locked L2 Cache through JTAG.

From JTAG, Read works properly but writes makes the specific cache line corrupted,

Step 1 : Initial Setup

     1. Wrote an application Which runs from OCRAM

     2. Load and lock entire L2 cache(pl310) to non existent address (physically not present SRAM address). L2 Cache is in Write-back, write-allocate mode

     3. After that verified the L2 cache data from application itself and it works

Step2: Read from JTAG - Proper

     Reading the L2 cache mapped locations from JTAG  (using xilinx XSDB console)  and it gives the application written value

Write through JTAG

Next, to check support for writing, we tried to write to a location in L2 cache from JTAG.

After writing, when we read back from same location through JTAG(using xilinx XSDB console) and application, we found that cache line size gets “corrupted”.

  

So could someone please tell me why locked L2 cache data get corrupted after writing through JTAG ? 

Thanks
Abhilash VR

Parents
  • Hi Abhilash,

    Can you expand on what you mean by "corrupted"? Is it that the data you wrote does not appear in the cache? Did you expect that you would or wouldn't be able to write to that line?

    Note that there's no way for the DAP access to directly read into the L2C-310, it would go via the ARM core, so your second and third diagrams are technically misleading -- that said, it isn't the diagram that would be the problem.

    It is technically possible that the Xilinx debugger (as with most debuggers) play games with the SCTLR.C bit and perhaps even the L2C-310 settings to effect a physical memory access which does not get intercepted by a cache, or may perform cache maintenance operations (lockdown only guarantees that a line would not be naturally evicted -- cache maintenance may still cause this which would not be desirable). How exactly are you enacting the write using XSDB (note, we can't support Xilinx's tools particularly, but it may give away a clue).

    Ta,

    Matt

Reply
  • Hi Abhilash,

    Can you expand on what you mean by "corrupted"? Is it that the data you wrote does not appear in the cache? Did you expect that you would or wouldn't be able to write to that line?

    Note that there's no way for the DAP access to directly read into the L2C-310, it would go via the ARM core, so your second and third diagrams are technically misleading -- that said, it isn't the diagram that would be the problem.

    It is technically possible that the Xilinx debugger (as with most debuggers) play games with the SCTLR.C bit and perhaps even the L2C-310 settings to effect a physical memory access which does not get intercepted by a cache, or may perform cache maintenance operations (lockdown only guarantees that a line would not be naturally evicted -- cache maintenance may still cause this which would not be desirable). How exactly are you enacting the write using XSDB (note, we can't support Xilinx's tools particularly, but it may give away a clue).

    Ta,

    Matt

Children
More questions in this forum