• Join
  • Sign In with my.TI Login
Texas Instruments
  • Products
  • Applications
  • Tools & Software
  • Support & Community
  • Sample & Buy
  • About TI
Sample & Purchase Cart Sample & Purchase Cart
  • Search
  • Advanced
TI E2E™ Community
  • Support Forums
  • Blogs
  • Groups
  • Videos
  • 简体中文
  • More ...
TI Home » TI E2E Community » Support Forums » Digital Signal Processors (DSP) » C6000 Single Core DSP » C64x Single Core DSP Forum » How to Tell When QDMA Transfer Has Completed
Share
C6000 Single Core DSP
  • Forums
  • Announcements
Options
  • Subscribe via RSS

Forums

How to Tell When QDMA Transfer Has Completed

This question is answered
Jon Kelm
Posted by Jon Kelm
on Jul 31 2012 12:22 PM
Prodigy90 points

I have a 6413 project with a hardware interrupt (HWI_INT4) that is triggered externally at 120 kHz.  At the beginning of this interrupt I set up the QDMA to read two 16-bit words from external memory, as follows:

  volatile unsigned int *base;
  base = (volatile unsigned int*)(_EDMA_QOPT_ADDR);
  base[_EDMA_QSRC_OFFSET]  = (unsigned int)source;
  base[_EDMA_QCNT_OFFSET]  = (unsigned int)count;
  base[_EDMA_QDST_OFFSET]  = (unsigned int)dest;
  base[_EDMA_QIDX_OFFSET]  = (unsigned int)0;
  base[_EDMA_QSOPT_OFFSET] = (unsigned int)0x29200001;

I then go on to execute some code in my interrupt that does not depend on the values to be read.  Eventually I hit a point where I can't continue until I've gotten the data from QDMA, so I want the processor to wait until the transfer has completed.

I have tried the following:

  while (!(EDMA_getPriQStatus() & EDMA_OPT_PRI_HIGH));

but that does not appear to work as expected (i.e., the processor seems to get past this line of code even though the transfer is not completed).

I have also tried setting the TCINT bit in QSOPT, leaving TCC and TCCM zero as above, and waiting for bit zero of CIPR to be set:

  base[_EDMA_QSOPT_OFFSET] = (unsigned int)0x29300001;   // replace corresponding line in setup above

  volatile unsigned int *base;
  base = (volatile unsigned int*)_EDMA_CIPR_ADDR;
  while (!(*base & 0x1));

However, this also seems to allow the processor to conitnue in cases where the transfer has not completed.

What is the recommended way to check for the completion of a QDMA transfer within an ISR?

EDMA QDMA 6413
Report Abuse
  • Reply
You have posted to a forum that requires a moderator to approve posts before they are publicly available.
All Replies
  • Jakez
    Posted by Jakez
    on Jul 31 2012 13:21 PM
    Verified Answer
    Verified by Jon Kelm
    Expert1870 points

    Hello,

    The TCINT method is the standard one; sure you actively reset the CIPR bit 0 after use (or before programming QDMA) ?

    Jakez

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Jon Kelm
    Posted by Jon Kelm
    on Jul 31 2012 13:50 PM
    Prodigy90 points

    Hi Jakez, thanks for the quick response.

    It seems like the problem may have been that I was resetting the CIPR bit after use, but not before programming the QDMA.  Does it make sense that this would lead to unexpected behavior?

    My sequence now is:

    1. Clear CIPR bit 0: EDMA_RSET(CIPR, 0x1)
    2. Set up QDMA source, count, destination, offset, and QSOPT
    3. Do stuff until I need the data
    4. Poll CIPR until bit 0 is set to 1
    5. Clear CIPR bit 0: EDMA_RSET(CIPR, 0x1)

    This appears to be working as expected.  Does it sound OK to you?  I'm guessing that step 5 is redundant with step 1 since I'm doing this repeatedly.

     

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Jakez
    Posted by Jakez
    on Jul 31 2012 22:13 PM
    Expert1870 points

    Hello,

    I meant the CIPR must be 0 before starting the transfer, by resetting it either before or after the repeated process (while before is preferable, ie step 5 may be suppressed).

    Jakez

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • RandyP
    Posted by RandyP
    on Jul 31 2012 22:54 PM
    Guru61625 points

    Jon,

    Step 1, clearing CIPR before the transfer begins, is a requirement for a reliable design. Without doing this before the transfer, you are counting on the device reset leaving this bit in the 0 state, and that is not a safe choice. You could do a soft reset or an emulation reset or branch to _c_int00 or many other things, and these could possibly leave the CIPR bit in the set state (1).

    Please follow Jakez' recommendation to use step 1 and suppress step 5.

    Regards,
    RandyP

    Search for answers, Ask a question, click  Verify  when complete, Help others, Learn more.

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Jon Kelm
    Posted by Jon Kelm
    on Aug 01 2012 05:51 AM
    Prodigy90 points

    Thanks Jakez and Randy. It's working now that I am clearing the CIPR bit in the appropriate place.

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
TI E2E™ Community
  • Support Forums
  • Blogs
  • Videos
  • Groups
  • Site Support & Feedback
  • Settings
TI E2E™ Community Groups
  • TI University Program
  • Make the Switch
  • Microcontroller Projects
  • Motor Drive & Control
Other Communities
  • Deyisupport
  • Designsomething.org
  • beagleboard.org
  • TI on Element 14
  • TI on TechXchangeSM
Other Technical & Support Resources
  • WEBENCH® Design Center
  • Product Information Centers
  • Technical Documents
  • TI Design Network
  • TI Technical Articles
  • TI Training

All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.

Follow Us Texas Instruments on Facebook Texas Instruments on Twitter Texas Instruments on LinkedIn Texas Instruments on Google+
TI Worldwide | Contact Us | my.TI Login | Site Map | Corporate Citizenship | mobile m.ti.com (Mobile Version)

TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs and
embedded processors, along with software, tools and the industry’s largest sales/support staff.

© Copyright 1995-2013 Texas Instruments Incorporated. All rights reserved.
Trademarks | Privacy Policy | Terms of Use