• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 103 subscribers
  • Views 861 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

L2 memory read problem in uninitialized areas

Angel Parra
Prodigy 20 points

We are using C6678 with SYS/BIOS 6.41.1 / compiler 7.4.8 / MCSDK 2.1.2.6 / MCADK PDK 1.1.2,.6

We have had two problems that appear to be related to the same root cause, an L2 read memory stall when the memory area being read from has not been written to before (i.e. contains uninitialized data).

The first problem happened on an SRIO read.  With an SRIO read to an area of L2 internal memory the SRIO transition stalled.  We observed that part of the area of L2 memory being read from was uninitialized.

The second problem is trickier to explain and to avoid too much explanation can be summarized as: a sporadic program fetch exception occurred when code was executed in L2 internal memory near uninitialized areas.

Both these issues were solved by initialising all the L2 internal memory address space during the boot process, but we are a little concerned that these problems may have been caused by something else and that this could cause other issues in the future.

Is it possible that after initialization the L2 internal memory could get in a state in which uninitialized (no one has still written to it) positions or areas present a read problem to SRIO and the core program fetch?  What could cause this?


Thanks,

Angel

  • 0
    TI__Guru* 81335 points

    Welcome to the TI E2E forum. I hope you will find many good answers here and in the TI.com documents and in the TI Wiki Pages (for processor issues). Be sure to search those for helpful information and to browse for the questions others may have asked on similar topics (e2e.ti.com). Please read all the links below my signature.

    We will get back to you on the above query shortly. Thank you for your patience.

    Thank you.

    Note: We strongly recommend you to create new e2e thread for your queries instead of following up on an old/closed e2e thread, new threads gets more attention than old threads and can provide link of old threads or information on the new post for clarity and faster response.

  • 0 in reply to Raja
    TI__Expert 4635 points
    Checking with Angel locally we have some more context.

    The SRIO issue is reproducible using some basic boot loader program code that just initializes the hardware using the platform library and waits for the application to be loaded trough the SRIO (using direct IO mode), if the boot application (that doesn’t need L2 memory at all) doesn’t initialize L2 memory and the host tries to read (through the SRIO using direct IO mode) some area of it, the SRIO transaction fails.

    Hopefully this helps narrow down the investigation.

    Regards,
    Garry
  • 0 in reply to Garry Clarkson
    TI__Genius 12805 points

    One thing that you can try is to disable the ECD

    Below is from 11.3.2 L2 EDC Logic Operation of core Pac http://www.ti.com/lit/ug/sprugw0c/sprugw0c.pdf

    The L2 EDC logic updates the stored parity information in response to every 128-bit

    write on a 128-bit boundary. It calculates the new parity and stores it in the parity RAM

    along with the valid bit. If the write is less than 128-bits or non-aligned to a 128-bit

    boundary, L2 updates the parity RAM to indicate invalid parity and zeroes the parity

    value.

     

    On reset, the L2 EDC logic is disabled. Programs enable the EDC logic by writing a '1'

    to the L2 Error Detection Command Register Enable bit (L2EDCMD.EN = '1'). The L2

    EDC logic does not initialize the parity RAM when transitioning from the disabled to

    the enabled state. Thus, upon entering the enabled state, there may be invalid parity

    values in the parity RAM whose corresponding valid bits are also set. To avoid false

    parity errors from L2 RAM, programs should follow the EDC setup sequence

    mentioned below.

    Ran

  • 0 in reply to ran35366
    Prodigy 20 points

    Great!!!!

     

    I made a quick test disabling the Error Correction at platform initialization level and it has worked.

    I will have a look to the enable procedure described in the documentation and the platform library code to find proper form to solve the problem.

     

    Thank you it has been a great help.

    Regards,

    Angel