• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 424 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.

Problems with C6713 with SDRAM and FPGA

Alex Bueno
Prodigy 120 points

 

 Hello!

 

 I am working with a custom board, which has a TI DSP C6713, as well as an external FPGA in CE2 and external SDRAM in CE0.

 I've been running the software in internal memory, and I have done RAM tests, and they are OK. Also I've been using the FPGA to read and write to UARTs, and it works fine also.

 But now I've tried to set my code to execute from SDRAM, and when I read from the UART (FPGA), I receive spurious incorrect data (10% of times).

 The only setting I have seen that could arrange this is the Turnaround Time (TA), that delays the access from one CE to another, but I have increased it and nothing changes...

 Any idea of what can it be?

 Thank you.

 Alex

  • 0
    TI__Guru 62975 points

    Alex,

    I'm not sure if we will be able to resolve a system issue like this over the forum, but can you provide more details on your application?

    Is cache enabled?  Is there a UART FIFO in the FPGA?  How are UART reads initiated?  Is it CPU-mastered or EDMA mastered?  Are there other concurrent processes in the background?  How fast are you running SDRAM?  Have you been able to scope the FPGA signals to see if the spurious data is from bad AC timing? 

    -Tommy

  • 0 in reply to tlee
    TI__Guru*** 125430 points

    Can you give more details on how the data is incorrect?  For example, if you are receiving a ramp function (0, 1, 2, 3, ...) what does the received data look like in the case of failure?  Ditto on Tommy's questions.

    If you have resolved your issue please post the resolution and mark the thread as answered.  Thanks.

  • 0 in reply to Brad Griffis
    Prodigy 120 points

     

     Hi!

     

     We have resolved the problem, but I don't know why exactly.

     The problem was that even that the UARTs had been configured as non-interrupt, and the interrupt was not being called (I checked with breakpoints), if I didn't call the clear_interrupt inside the UART IRQ, the software behaved incorrectly. Once I declared the clear_interrupt, and disable and enable inside the UART IRQ, everything is working fine.

     

     It's very strange, because the UARTs are not generating interrupts, and the interrupts are not entering, but if I don't write the correct IRQ, there are problems.

     So... the problem is solved, but I don't know why exactly.

     Alex