• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 99 subscribers
  • Views 315 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.

Conflict between GPVAL accesses and SDRAM accesses in C6412

Luca Zardo
Prodigy 40 points

Hi all, we have designed a board based on C6412. The C6412 acts as PCI interface for the board: on the EMIF we have connected the C6412 SDRAM and some external peripheral chips. The HOST performs slave PCI accesses to the C6412 in order to access the peripherals connected to EMIF. The C6412 makes PCI master accesses to the HOST for the data that require fast communication between the DSP and the HOST. The HOST is a standard x86 based PC motherboad and our board is inserted in a standard PCI slot. Most of the C6412 firmware (program code) is located in L2 memory. This is the code that requires fast execution.

Only a small part of the program is located in the C6412 SDRAM. We are not using any L2 additional cache (L2 cache size is zero). The host uses C6412's GPIOs (reads GPVAL register through non-prefetchable PCI accesses) in order to verify the status of one of the peripherals. We have noticed that when GPVAL reads are performed by the host the behavior of the C6412 FW is corrupted, as if C6412 does not fetch program code or data correctly from its SDRAM. On the contrary, if we remove host read accesses to GPVAL, the behavior of the C6412 FW is perfect. We have made a second test. We have changed the program code allocation, i.e. moved all the program code to L2 memory (just for test, of course) and checked the behaviour of C6412 while the HOST performs read accesses to GPVAL. In this case the behaviour of the C6412 program is correct. In order to better verify this behavior, we have made a third test too.We have alternated host's read accesses to GPVAL and to EMIF SDRAM. In some cases, after the host read access to GPVAL, the host read access to SDRAM returns corrupted data. It seems that the SDRAM read access returns bad data, but does not corrupt SDRAM data. When the host stops reading GPVAL, the HOST read accesses always return correct data. We also verified that the same situation occurs if we make host read accesses to other C6412's peripheral registers (i.e. RSTSRC) instead of GPVAL. Our questions are:

1) Did you know that GPVAL (and other accesses to C6412 internal register though non-prefetchable address space) may lead to corrupted read accesses to the C6412 SDRAM?

2) Is it possible that we are not correctly using some part of the C6412 DSP or that we have forgot some necessary configuration? Can you provide us any suggestion? Thank you very much in advance. Best Regards.

  • 0
    TI__Guru* 84110 points

    Luca Zardo,

    Can you describe the corruption, please? Correlation to other nearby SDRAM values or sequential values could help understand what you are observing.

    Can you capture the EMIF signals on a logic analyzer to determine whether the correct data is coming in to the DSP and getting corrupted or whether wrong data is coming from the SDRAM? Or does the corruption occur on writes?

    What PCI address is the host accessing? Which BAR is that going to? To what base address is that BAR mapped?

    Can the host access the SDRAM and would still cause the corruption, or is it only when accessing memory-mapped registers?

    Regards,
    RandyP

  • 0 in reply to RandyP
    Prodigy 40 points

    Hello RandyP,

    RandyP said:

    Can you describe the corruption, please? Correlation to other nearby SDRAM values or sequential values could help understand what you are observing.

    Can you capture the EMIF signals on a logic analyzer to determine whether the correct data is coming in to the DSP and getting corrupted or whether wrong data is coming from the SDRAM? Or does the corruption occur on writes?

    Unfortunately we do not have many details about the corrupion itself and, at the moment, we do not have the possibility to make deeper tests with a logic analyzer.

    When we alternate reads to GPVAL and reads to a SDRAM counter (incremented every 250us using a thread posted by an HWI), the host eventually reads an inconsistent value of the counter then it returns reading again a correct value. After that the value is no more incremented by DSP due to the stop of correct code execution.

    Our conclusion is that DSP may experiece the same problem that occurs to the host reading wrong code/data from SDRAM.

    RandyP said:

    What PCI address is the host accessing? Which BAR is that going to? To what base address is that BAR mapped?

    These are host's addresses:

    Mem/IO space 0 | FCC00008:00400000
    Mem/IO space 1 | FE000000:00800000
    Mem/IO space 2 | 0000EC01:00000010

    The host makes accesses to memory mapped registers through BAR1; the problem appeared also making accesses to GPVAL through BAR0.

    RandyP said:

    Can the host access the SDRAM and would still cause the corruption, or is it only when accessing memory-mapped registers?

    We experienced the problem only when the host makes read accesses to some memory mapped registers. For example we were able to systematically reproduce the problem accessing GPVAL or RSTSRC; however, accesses to memory mapped DSPP did not cause the problem.

    Making acceses to DSP's SDRAM and/or L2 memory we were not able to reproduce the problem.

    In fact, in order to patch the problem, we moved the host's read accesses from the value of GPVAL to a new peripheral register mapped to EMIF and the problem disappeared.

    Thank you.

    Regards,

    Luca.