• 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 » Microcontrollers » C2000™ Microcontrollers » C2000 32-bit Microcontrollers Forum » BRKDT on F28335
Share
C2000™ Microcontrollers
  • Forums
  • Announcements
  • E2E Wiki
Options
  • Subscribe via RSS
C2000 Resources
  • Product Folder
  • C2000 Training Portal
  • C2000 Technical Training Catalog
  • C2000 Datasheets, App Notes, User Guides
  • C2000 Hardware Design Kits
  • controlSUITE for C2000 Software Library


  • InstaSPIN Resources
  • What is InstaSPIN?
  • Videos and Support


  • InstaSPIN-FOC and InstaSPIN-MOTION Resources
  • What is InstaSPIN-FOC?
  • What is InstaSPIN-MOTION?
  • Product Folder: F28069F, F28068F, F28062F, F28068M, F28069M
  • User’s Guide
  • Technical User’s Manual
  • Tools
  • Forums

    BRKDT on F28335

    This question is not answered
    Robert Boissel
    Posted by Robert Boissel
    on Aug 01 2012 13:59 PM
    Prodigy90 points

    Hello,
    I'm facing something strange.
    I use the three SCI on my MCU with good efficiency except in one case.
    Time to time, a break occur "SCI receiver data line (SCIRXD) remains continuously low for at least ten bits".
    The ISR reset the SCI and it's OK.
    But sometime, the SCI stays stuck. (The break could be far far longer than ten bits).
    This kind of break is not normal (hardware problems) but normaly, the SCI should manage it ?

    Thank you for your help.

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    All Replies
    • Vamsi Gudivada
      Posted by Vamsi Gudivada
      on Aug 01 2012 14:58 PM
      Intellectual2935 points

      Robert,

      If the receiver line of C2000 SCI is being held low continuously for 10 bits or more after a missing stop bit, SCI gets a break condition and will hit error ISR.  If the receiver line is not pulled high even after the ISR clears the BRKDT with a reset, SCI will again hit the break condition and hence ends up in error ISR repeatedly.  Hence, it is up to the application hardware to keep the receiver line high when there is no communication.

      Thanks and regards,
      Vamsi

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Robert Boissel
      Posted by Robert Boissel
      on Aug 02 2012 01:39 AM
      Prodigy90 points

      Vamsi,

      Thank you for your quick answer.

      That you explain is exactly what I was expecting, and it occurs the main time.

      But time to time, the SCI blocks and stop firing interrupt.

      What I want to know is: is it a normal reaction facing to an abnormal hardware situtation or there is something else ?

      Thank you,

      regards

      Robert

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Vamsi Gudivada
      Posted by Vamsi Gudivada
      on Aug 02 2012 12:02 PM
      Intellectual2935 points

      Robert,

      Are you saying that at times SCI is not firing the interrupt when a valid character is received OR when the break happens?

      Please note that once a breakdetect occurs, no more characters will be loaded in to receive buffer until SCI is reset.  May be the valid character is being sent by host even before the SCI was reset to bring it out of BRKDT condition.

      Thanks and regards,
      Vamsi

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Robert Boissel
      Posted by Robert Boissel
      on Aug 02 2012 13:12 PM
      Prodigy90 points

      Vamsi,

      It's exactly the problem, during the long "break" several interrupts are fired, until the "break" stop.

      But some time the SCI block before the "break" stop. And not more interrupt is fired (valid characters or break).

      Thank you en best regards,

      Robert

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Vamsi Gudivada
      Posted by Vamsi Gudivada
      on Aug 02 2012 13:30 PM
      Intellectual2935 points

      Robert,

      From your reply, looks like you exactly dont know when the break or valid data is being sent from host.

      It might be that just after the SCI reset in the ISR, a valid data did get received instead of a break but the FIFO levels might not have matched yet to generate an interrupt.  Hence you might not be receiving any interrupt.  Are you sure that the RX line is always pulled low by the host when there is no data?  OR it sometimes gets pulled high and sometimes gets pulled low when there is no data transfer?

      Reason I am asking is that there might be a chance of valid data occurence as I mentioned above and then the line is being pulled high later and hence did not see an interrupt because of not matching FIFO levels yet.  Are you using FIFO?

      Thanks and regards,
      Vamsi 

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Robert Boissel
      Posted by Robert Boissel
      on Aug 02 2012 15:55 PM
      Prodigy90 points

      Vamsi,

      The sequence is following:

      The RX line is pulled low for almost 200ms then pulled high. The real transmition starts few hundreds ms after.

      Thank you for your help

      Regards

      Robert

       

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Vamsi Gudivada
      Posted by Vamsi Gudivada
      on Aug 03 2012 16:15 PM
      Intellectual2935 points

      Robert,

      You did not mention whether you are using FIFO or not?

      If yes, what is the value that you set for RXFFIL bits?  Now that you confirmed that the RX line is pulled up after some time, as I explained, it might be that the valid data did come in to FIFO but did not match the level bits and hence did not get an interrupt.  Are you sure that the host sent valid data and that host sent enough characters such that the RXFFIL bits would generate an interrupt?

      Why dont you disable the RX for the duration when the line is pulled low?

      Thanks and regards,
      Vamsi 

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Robert Boissel
      Posted by Robert Boissel
      on Aug 07 2012 05:39 AM
      Prodigy90 points

      Vamsi,

      Sorry for the delai, I am out of office for 2 weeks.

      For your question, yes I use the fifo, and most of the time all work fine.

      But after the long "break" has occured, the data sent by the host are valid (verified by a scope) but the SCI do not detect these datas (the fifo is empty).

      The only way to restart de reception is reseting the SCI (by the reset bit of the control register)

      Thank you for your help

      Robert

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Vamsi Gudivada
      Posted by Vamsi Gudivada
      on Aug 08 2012 12:30 PM
      Intellectual2935 points

      Robert,

      Could you set the RXFIFO level match bits (RXFFIL) to 1 and see whether you are able to receive data or not?

      Thanks and regards,
      Vamsi

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Robert Boissel
      Posted by Robert Boissel
      on Aug 11 2012 03:49 AM
      Prodigy90 points

      Vamsi,

      I will try when I will be back to my office in 1 week.

      Thank you

      Robert

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Robert Boissel
      Posted by Robert Boissel
      on Aug 22 2012 12:58 PM
      Prodigy90 points

      Hi Vamsi,

      I think, I have found the problem.
      We used the FIFO, but the bit "RXERRINTENA" of the SCICTL1 register was not set.
      We made a mix, in the error management, between the two modes (with or without FIFO).
      In fact I wonder how it could work (the system was running perfectly until we made hardware modifications).

      One more little question: The FIFO fire and interrupt when RXFFST match RXFFIL.
      But, if the flow of data stop, and few bytes stay in the FIFO, what is happening?
      For example, an answer frame, made with 18 bytes is received.
      If the FIFO is set with RXFFIL=8, it will fire 2 interrupts (16 bytes), so 2 bytes will stay in the FIFO?
      I noticed that it is not the case, (maybe a timeout?), but I did not find, in the SCI reference guide, a description of this.

      Thank you for kindness

      Best Regards

      Robert

      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