Loading ...
Sorry, an error occurred while loading the content.

144Re: Flushing the cache after turning it off

Expand Messages
  • rsprowson
    Feb 25, 2006
      Right then - replying to myself, here's what fixed the problem for me:

      1. Decided to leave the locking as it was
      there are 4 ways, but only up to 3 can be locked (the defines are
      slightly confusingly named) - this has the effect of setting the nth
      way to be in load mode, and the previous n-1 ways are locked:

      Loading way 0 => no ways locked obviously!
      Loading way 1 => way 0 is now locked
      Loading way 2 => way 0 and 1 now locked
      Loading way 3 => way 0 and 1 and 2 now locked

      Way 3 gets confusing since I guess either the loaded 2k of dummy data
      or the cache flushing code could end up in the cache, but as long as
      we load 2k of something and pending writes will be forced out.

      When reenabling the cache all ways are unlocked anyway, you may need
      to think more if you're selectively flushing just some of the cached
      regions (in my code I have the SDRAM and ROM cached, but only ever
      have both or neither cached, not one or the other).

      2. Tried with and without the FLUSH_FLUSH write
      I'm with Ken here that it should be in there in his example code (as
      I also lock as described in (1) above, it's not really essential for

      If you're flushing when selectively disabling banks, it would need a
      FLUSH_FLUSH, but for me globally disabling it there's little point
      wasting 128 cycles since I do a FLUSH_FLUSH when reenabling the cache

      3. And the magic change was...
      Neither (1) nor (2) actually made any difference. The difference was
      to use a bank for the dummy read which is currently marked as
      cacheable and a section of it which would never have been seen before
      by the cache.

      Previously I'd just been using somewhere (64k AND NOT 0x1FFF) away
      from the cache flush loop, but as there's about 100k of code I would
      have visited some of those locations already.

      Fortunately, as the code is in the internal ROM, and the ROM is
      marked as cacheable, I can simply use the top half of bank 25
      (normally for external flash which is unused).

      Previously my test would survive about 5s before bailing out with an
      abort on data transfer (LDMIA'ing from a dodgy address), but has been
      running all night,

      --- In OKI-ARM-mcus@yahoogroups.com, "rsprowson" <news@...> wrote:
      > --- In OKI-ARM-mcus@yahoogroups.com, "kendwyer" <kendwyer@> wrote:
      > >
      > > Hi,
      > >
      > > Note the following: "Since the CPU will be made to wait until the

      > cache memory initialization has been completed. The instruction
      > > of writing to the FLUSH register will take about 128 instruction
      > > cycles."
      > Though equally 9.2.1 says "A locked way will not be flushed even
      > a flushing operation is made using the FLUSH register.", which is
      > I queried it. I interpret the FLUSH register as only being useful
      > initialisation, not when disabling, though that's open to Oki's
      > ambiguity.
      > Quick question: in your test code you have
      > CACHE_CON_WAYn | CACHE_CON_LOAD | CACHE_CON_LOCK0 (for n=0 to 3)
      > whereas I have
      > CACHE_CON_WAYn | CACHE_CON_LOAD | CACHE_CON_LOCKn (for n=0 to 3)
      > was that just a copy and paste error?
      > Cor this is turning out to be more of a headache than I'd thought!
      > Sprow.
    • Show all 8 messages in this topic