• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 84 subscribers
  • Views 869 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.

CCS/TMS320F28377S: EMIF data not copied correctly to a local buffer

Javier Alvarez
Prodigy 230 points

Part Number: TMS320F28377S

Tool/software: Code Composer Studio

Hi,

We have an EMIF interface with an external chip. I'm currently debugging it with CCS, but I see the following behavior: The memory has the correct values, but once I got that (with a simple for, nothing complicated) I get random zeroes. So, for example, in the memory window, address 0x102A00, I see the following sequence (which is what I expect)

0005 1F41 0080 0151 0501

but once I copy the values into a buffer to be used by the application layers, I see random zeroes. For example I can read

0005 1F41 0000 0151 0501

or

0005 1F41 0000 0151 0000

I'm just guessing, but can it be that there's a concurrency problem? If so, how can I ensure that I have exclusive read access while copying the buffer? Or could this be related to something else?

(Edit):

Summarizing:

In the CCS memory browser, the data from the FPGA looks correct.
A function used to access the information uses a for cycle to copy data from the designated ram into another buffer (app layer).
The buffer ends up with one or two words corrupted with zeros. Sometimes one, sometimes two.
A step by step copies the data properly.

  • 0
    TI__Guru*** 125430 points
    Does changing the CCS memory view from 16-bit to 32-bit change the data being read?

    Is your code that's reading the data reading 16-bit values or 32-bit values (i.e. what is the pointer type)?

    Have you tried stepping through the copy code? Does it read correctly when you single step through it?

    What is the external chip? Is it an SRAM? FPGA? Does it have any requirements for the chip select to de-assert between successive accesses?
  • 0 in reply to Brad Griffis
    Prodigy 230 points
    The pointers are 16 bits
    Stepping through the code gives me proper values (but I saw, for a fraction of a second, a change in the memory browser to all zeros)
    The external chip is an FPGA.

    I'll do some digging to answer the rest of your questions.
  • 0 in reply to Javier Alvarez
    TI__Guru*** 125430 points
    Sounds like a timing issue at the memory interface... If possible you should try to get a logic analyzer hooked up so we can better understand the issue and validate your timings.
  • 0 in reply to Brad Griffis
    Prodigy 230 points
    I'll check if this can be done and post the results.

    Besides going there: is there a register or something that can be used to pause the communication between the DSP and the external chip? Or maybe to freeze the memory before it is read? Or maybe it is a design problem that I communicate with the rest of the team (such as: wait until X register has some value, stop the communication, read only in this window, re-enable communication).
  • 0 in reply to Javier Alvarez
    TI__Guru*** 125430 points

    Javier Alvarez said:
    Besides going there: is there a register or something that can be used to pause the communication between the DSP and the external chip?

    That's more or less what's happening when you single step through the code.  If the external device needs to pause/delay communication there's a WAIT pin for that purpose.

  • 0 in reply to Brad Griffis
    TI__Guru** 117301 points
    Hi Javier.

    Have you tried changing the READ timing (specially strobe timing) in ASYNC configuration register to see if that helps?

    Regards,

    Vivek Singh
  • 0
    Prodigy 230 points
    Sorry it took me so long to look back at this thread, but I was not the owner of the code (only a user).

    At the end, this issue was in how the FPGA was configured: it handles communication, and it was signaling the start of the reception instead of signaling when the reception was complete. So the randomness was due the fact that sometimes my program would check for the flag too close to the reception start.

    Thanks for all your support.
  • 0 in reply to Javier Alvarez
    TI__Guru** 117301 points
    Thank you for the update. I am glad that issue is resolved.