• 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) » OMAP™ Processors » OMAP-L13x, AM1x and C674x Processors Forum » receiving uart data using edma with parallel MCasp edma
Share
OMAP™ Processors
  • Forums
  • Announcements
Options
  • Subscribe via RSS
Resources
  • OMAP-L1x DSP+ARM9™-based Processors Product Folder
  • OMAP3525/30 DSP+ARM Cortex™-A8-based SOCs Product Folder

  • Top OMAPL Wiki Links
  • OMAPL3x Schematic Review Checklist
  • OMAPL13x Boot resources

  • OMAPL Document Resources
  • OMAPL137 Technical reference manual
  • OMAPL138 Technical reference manual
  • OMAPL Boot loader App Notes
  • receiving uart data using edma with parallel MCasp edma

    receiving uart data using edma with parallel MCasp edma

    This question is not answered
    alon yaish
    Posted by alon yaish
    on May 02 2012 08:38 AM
    Prodigy40 points

    hi,

    i am using a preexisting edma setup for the MCasp and i am trying to use the edma for getting data from the uart (uart2) by setting up another edma channel that triggers a different interrupt. 

    the first problem is that the dma does not read more than on word from the uart and the uart (in fifo mode) does not clear so that the next word can be read. although, the interrupt does occur so i can "manually" read from the uart's RBR every interrupt enabling me to get the data from the uart.

    this leads to the second problem that is that when i combine the two codes (one for the MCasp and one for the uart) and want to work with both interrupts (i have set the uart's SWI to be at a higher priority) the uarts interrupts do not always work and some data is absent. i was thinking that this could be related to the "event queue" for the dma but its just a hunch. is there anything important to change in the edma's setup if i want different edma events on different channels? (there are two events for the MCasp- event0 and event1, and event 30 for the uart2).

    i am working with a logicpd experimenters board with an omap-l138.   

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    All Replies
    • Raghavendra Maddikery
      Posted by Raghavendra Maddikery
      on May 03 2012 09:44 AM
      Expert5500 points

      Hi Alon,

      alon yaish
      although, the interrupt does occur so i can "manually" read from the uart's RBR every interrupt enabling me to get the data from the uart

      Are you using BIOS PSP? If so, could you please mention which version of the PSP are you using? Looking at your post I think you are configuring UART in DMA mode only. 

      Have you tried executing the sample application binaries that come with the PSP? Or, have you tried just running the UART alone? If so, what is the behavior?

      Let me know..

      Best Regards,

      Raghavendra

      Does this help with your question? If not, please send back more information. If it answers your question, please click the  Verify Answer  button below.

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • alon yaish
      Posted by alon yaish
      on May 09 2012 03:01 AM
      Prodigy40 points

      hi Raghavendra, 

      i am not using bios psp and haven't tried executing the sample application binaries.

      i have been using the uart as configured in a uart demo.

      running the uart alone using an interrupt generated by the dma works fine for and interrupt every byte received, and fine after the first 3 byte if the dma is configured to generate an interrupt every 3 bytes recieved.

      when i worked with the uart alone, there was a problem that the dr bit was not always indicating that there was data ready in the fifo. in my application i recieve communication to the uart in 3 byte words, sometimes after reading the first byte (under the statement (if (DR==1))) , if i would try to read from the uart again right after that, the DR byte would still be '1' and i would receive junk from the uart. i thought that this was due to the speed of the change from 1 to 0 of the data ready byte, but maybe its not and its related to the problem.

      thanks,

      alon

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • David Friedland
      Posted by David Friedland
      on May 09 2012 11:29 AM
      Genius13420 points

      Alon,

      Since you are not using the BIOS driver software packages, I have moved this thread over to the OMAP-Lxx forum in hopes that you will be able to get a faster response to your question there.

      Dave

      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