• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 293 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.

QDMA read from PCI space fails on DM648

Geoff
Prodigy 195 points

We are using DM648, and EDMA3 LLD and have access to external shared memory via PCI. If we try to read this shared memory using QDMA (from PCI to L2) the data read is not valid (was always zero in our tests), however if we perform the same transfer with DAT (EDMA) it works OK. We validate the QDMA call by moving data L2 to L2 first and that is OK. We have validated the data in PCI using CPU copy and that is OK also. There is no error reported by the EDMA3 LLD when the QDMA completes.

Can anyone explain this behavior or add any information? Have you had any similar problems with QDMA and PCI?

Thanks, Geoff

  • 0
    TI__Guru* 84110 points

    I am surprised that your DAT functions do not use QDMA.

    There is no difference between the transfers executed by QDMA or by DMA channels, they all use the same EDMA3 resources. This depends on how the individual QDMA and DMA channels are configured.

    The most likely cause, other than simple programming errors, is the two different transfers used different Transfer Controllers and that the QDMA's TC is not mapped to access the PCI or L2. You can check the datasheet for the Connectivity Matrix to see if your QDMA configuration needs to be changed.

    Regards,
    RandyP

     

    If this answers your question, please click the  Verify Answer  button below. If not, please reply back with more information.

  • 0 in reply to RandyP
    Prodigy 195 points

    Thanks for your reply Randy. Please spell out exactly what you are saying about some TC not being able to reach PCI or L2. I am not aware of any asymmetry in the EDMA3 of DM647/648! However, we do have different priority and burst size for different TC, but this should not be the problem.

  • 0 in reply to Geoff
    TI__Guru* 84110 points

    The Connectivity Matrix in the datasheet details which masters are connected to which slaves. If you are not following this, then my guess may be right.

  • 0 in reply to Geoff
    Prodigy 195 points

    Randy,

    Thanks for explaining the problem with accessing the PCI.

    Perhaps you could explain another DMA/PCI 'strangeness'? Before we can successfully dma from the DSP into the host memory, we have found that we have to use the  cpu to read and write the host memory. If we only read, the DMA's work for many minutes, but eventually the pci bus seems to 'lock up'. We are seeing some hangs after hours when we do the read and write and (as yet) haven't confirmed that these are related to PCI.

     

    Can you speculate as to why these cpu read/write operations are necessary to have the pci dma's 'work'? What do you think the overall problem is if we are having dma/pci problems?

     

    Thanks

  • 0 in reply to Geoff
    TI__Guru* 84110 points

    Geoff,

    My recommendation is to check the errata for anything that might fit how you are using the PCI.

    Your description sounds like the DMA writes are not in need of initialization, since they do work for potentially millions of transfers.

    If it were me, I would look into the actual symptom of 'lock up' to figure out what that means. It will get you closer to a solution than anything I can think of.

    Regards,
    RandyP