• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 495 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

66AK2H12: L1P cache line can not sync with L2 memory

Thomas Yang55737
Expert 6356 points

Part Number: 66AK2H12

Hi  Expert,

My customer found a issue that one  L1P cache line  value (marked as red in below pictures)can not automatically sync up L2 memory value of function(Timer64_Init). The dirty bit in cache status is "0". The result will cause system crash.

The L2 memory value is 0x021FECA3 0x019839A0

The L1P cache line value is 0x0006CF10 0x00008000

The issue only occurred when the function (Timer64_Init) located in a special memory address(0x17877FF0).

If customer changed the function code memory map from 0x17877FF0 to 0x17878000, the issue disappeared,

or   make a cache L1P all invalid before the function call, the issue also disappeared. Issue disappeared means that the L1P cache line value can sync up the L2 memory and running successfully. 

Customer push for the root-cause on this issue, could you help it?

  • 0
    TI__Mastermind 25535 points

    Dear Thomas,

    Good day!.

    I think, they have the matching case of "Conflict misses occur when the cache has recently evicted a block of code that is now needed again" given in the wiki below.

    For L1 cache conflicts, please check whether the attached wiki document helps :- Program_Cache_Layout_Texas Instruments Wiki.pdf

    Regards

    Shankari

  • 0 in reply to Shankari G
    TI__Expert 6356 points

    Hi  Shankari,

    To me, L1P Cache conflict missed in your above comment should only impact the performance, but should not get to wrong result, L1P cache miss occurs frequently if interleaved functions are called, when L1P cache miss, the L1P controller fetches the line from L2 memory
    and stores the data in cache line frame . The tag portion of the address is stored in the tag RAM and the valid bit is changed to 1 to indicate that the set now contains valid data. The fetched data is also forwarded to the core, and the access is complete. But in customer case, it seems that the L1P controller doesn't fetch the line from L2 memory when L1P cache miss. The L1P line still keep the old data not the new expected data from L2 memory. The core used the old cache line data and then crash. Do you have any new comment based on the above clarification?

    Thanks

    Thomas

  • 0 in reply to Thomas Yang55737
    TI__Mastermind 25535 points

    Thomas,

    I understand.

    Thanks for the detailed note.

    Any possibility of creating a test project to reproduce this error ? So that we can run from our end and look into this error, closer ?

    Regards

    Shankari

  • 0 in reply to Shankari G
    TI__Expert 6356 points

    HI Shankari

    After many test, the issue can not reproduced through a small test project which download *.out through JTAG. The issue only occurred in real download case, that means DSP image load by ARM core. We suspect emulation reset may make L1P cache flush. Other observation is that If DSP image load by ARM core, before initialization code running, add L1P cache all invalidation command, the issue disappeared. Any idea?

    -Thomas

  • 0 in reply to Thomas Yang55737
    TI__Mastermind 25535 points

    Thomas,

    Nice catch!.

    If the error is not reproducible when the same program run through JTAG emulator, then consider these things.

    1. In gel file of 66AK2H12, how L1P cache is initialized and configured...Compare the same sequence with the source code.

    2. In the gel file, I could observe that the cache are set into some predefined values... Please do check those...Is that followed in the source code too

    (sample, gel out of C6657 board. You may have to check for the 66AK2H12 board and  the lines of gel which pops out about the cache...

    C66xx_0: GEL Output: Setup Cache...
    C66xx_0: GEL Output: L1P = 32K
    C66xx_0: GEL Output: L1D = 32K
    C66xx_0: GEL Output: L2 = ALL SRAM
    C66xx_0: GEL Output: Setup Cache... Done.

    3. In your previous post, you stated ," If customer changed the function code memory map from 0x17877FF0 to 0x17878000, the issue disappeared" 

    ---Check for any memory overlapping / memory leakage etc as well as "review the memory segments alloted" ----

    ----

    This statement of yours is confusing ----- "DSP image load by ARM core" ----> Might be a typo error?

    Because, DSP image cannot be loaded on ARM core. The Image built for ARM can only be loaded on ARM core?

    ----

    When you say ... "the real download case" , Are they flashing into NOR memory? 

    -----

    It is a good method to  invalidate the "L1P cache" as I could see the same in the gel file too. This can act as a "work around" !.

    ----

    The root cause can only be possible, if we could reproduce the issue from our end.

    That too, if the issue is intermittent, it will be even more difficult.

    Regards,

    Shankari G

  • 0 in reply to Shankari G
    TI__Mastermind 25535 points

    Dear Customer,

    With the work around of "invalidating the cache"..., are you able to sustain?

    Until, I hear from you, changing the status of this thread as closed.

    Once you reply, automatically the status of this thread will get opened.

    Regards

    Shankari G

  • 0 in reply to Shankari G
    TI__Mastermind 25535 points

    Dear Customer,

    With the work around of "invalidating the cache"..., are you able to sustain?

    Until, I hear from you, changing the status of this thread as closed.

    Once you reply, automatically the status of this thread will get opened.

    Regards

    Shankari G