AnsweredAssumed Answered

CodeWarrior Cache view does not behave as expected (or e5500 issue?)

Question asked by Mathias Parnaudeau on Oct 2, 2015
Latest reply on Oct 19, 2015 by Mathias Parnaudeau



I use CodeWarrior Development Studio 10.4.0 with a T1040RDB board. I am investigating a strange behaviour around L1 caches of the e5500 core (mine is Version: 2.0, 0x80241020) . I wanted to find help with the Cache view in CodeWarrior but that is even more strange...


Are there any errata documents about e5500 caches? I haven't found.


Anyway, here is the initial purpose of my post:




U-Boot locks 3 ways of the L1 data cache. When I stop U-Boot with the CodeWarrior debugger (just after the DRAM initalization) to inspect the cache, I see:


All locked cache lines have a different address and LRU but other properties are the same:

- Dirty: Yes

- Lock: Yes

- Valid: Yes

- Share: No

- Data: zero values


Comments and questions


1. The first strange point is the data content. U-Boot locks some ways to use this space as memory. Is the view known to miss some things (like data display)?


2. In the cache view context menu, I choose "Flush" but the only property that changes is "Valid", that is set to "No". That should not change this property but "Dirty".

If instead of "Flush", I choose "Invalidate", properties "Dirty" and "Valid" are set to "No", as expected.


3. Still from the menu, if I choose "Invalidate Line" or "Flush Line", the result is the same: lines are turned "Dirty: Yes" and "Valid: No". That does not seem to be coherent.


4. Setting a breakpoint in the U-Boot code, I execute flush_dcache(), that has no effect, I still see: "Dirty: Yes", "Lock: Yes", "Valid: Yes"... The lines should be cleaned.

Just after, I call invalidate_dcache(), and I get: "Dirty: No", "Lock: Yes", "Valid: No".


5. After a printf, I see that some lines are shown are "Lock: No"! How is it possible? Is there a problem with the "Cache" view or in an lower-level part?