Tool/software:
Hello,
My customer is encountering the following issue with L2 memory:
The two things that seems to be consistent with the intermittent testing failures of L2 at startup.
- Data is being written to the wrong address.
- It always on the first time of writing and reading back that it occurs.
L2 is tested by writing a 0x55555555 and then reading it back.
Not always, but sometimes the DSP doesn’t read back the 0x55555555 but 0x00000000.
And it was found that a different address had the 0x55555555 data.
For example when writing to address 0x00036000 the 0x55555555 data was written to 0x000032000
|
Address that we wanted to write to |
Address that was actually written to |
|
0x00036000 |
0x00032000 |
|
0x00039000 |
0x00031000 |
|
0x00039010 |
0x00031010 |
|
0x00039100 |
0x00031100 |
|
0x00039210 |
0x00031210 |
|
0x00038100 |
0x00030100 |
|
0x00038200 |
0x00030200 |
Address was off by 0x4000 or 0x8000. (Address lines 14 and 15)
Additional Details:
We found out the following about reading the L2 internal memory:
- The problem on reading L2 memory is only the first time at startup.
- It is intermittent, the frequency is about 1 out of 5 startups.
- They are using L2 Mode 000
- If the code executes a cache_invalidate (pushing out the L1 cache) first before writing and reading the L2, the problem appears to be solved.
What is causing this issue?
Thank you!
John
