• 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 » Hercules™ Safety Microcontrollers » Hercules™ Safety Microcontrollers Forum » NHET functionality different with debug probe attached vs removed
Share
Hercules™ Safety Microcontrollers
  • Forum
  • E2E Wiki
Options
  • Subscribe via RSS

Forums

NHET functionality different with debug probe attached vs removed

This question is answered
Marco Moreno
Posted by Marco Moreno
on May 01 2012 18:22 PM
Intellectual300 points

Hi,

I have some NHET code that has been developed while using the Green Hills SW debugger.  I have the CortexR4 code programmed in flash and the system starts up and runs as long as the debug probe is attached.  Once the probe is removed, the CortexR4 continues to run normally, but the NHET does not continue to function normally, but it does look like it's still running.  I have verified that at least one PWCNT instruction continues to run as expected with the debug probe removed, but there is an ECNT instruction that seems to not be responding to an edge trigger as normal.  The way the edge trigger is with these instructions:

PULSE_SYNC_RB   ECNT { next=LINEFAULT_PULSE,cond_addr=LINEFAULT_TRIGGER,pin=11,event=FALL,reg=NONE,irq=OFF,data=0}

LINEFAULT_TRIGGER MOV32 { remote=LINEFAULT_PULSE,type=IMTOREG&REM,reg=NONE,data=0}

LINEFAULT_PULSE PWCNT { en_pin_action=ON,pin=1,hr_lr=LOW,action=PULSELO,data=0}

So it can be seen that the PULSE_SYNC_RB instruction will normally transfer execution past the LINEFAULT_TRIGGER instruction to the LINEFAULT_PULSE instruction.  However, when the edge trigger is received on pin 11, the LINEFAULT_TRIGGER instruction is executed and will copy its data field to the LINEFAULT_PULSE instruction in order to start an output pulse on pin 1.  The LINEFAULT_TRIGGER data field is programmed by system software at run time.

This all seems to work fine with the debug probe attached, but when disconnected, the PULSE_SYNC_RB edge is still present on pin 11, but the LINEFAULT_PULSE stops outputting on pin 1.  There does seem to be some correlation between the nTRST line and the LINEFAULT_PULSE on pin 1.  I have captured on a logic analyzer that the LINEFAULT_PULSE normally begins 2us after the PULSE_SYNC_RB edge, which would correspond with my 1MHz NHET execution rate.  In my capture, as the debug probe is removed, the nTRST line is pulled down to ground (it is high while the probe is connected), and about 1.9us later I get a LINEFAULT_PULSE on pin 1.  After that, no more LINEFAULT_PULSE transitions occur until the probe is reattached, some toggling of nTRST occurs and another falling edge of nTRST happens, which causes another LINEFAULT_PULSE 1.97us later.  After that, it seems that some communications happens on the debug bus and then LINEFAULT_PULSE begins to act normally again.

After reading a bit about the nTRST role in NHET debugging, I understand there can be some interaction, but it seems that none of it should matter since I don't have any debug bits set in my HET code.  The documentation indicates that nTRST = 0 means "Functional mode" and nTRST = 1 means "Test/Debug mode".  My NHET code is only working in "Test/Debug mode" it seems.  Can someone clue me in on what I'm missing here?

Thanks,

Marco

NHET tms570
Report Abuse
  • Reply
You have posted to a forum that requires a moderator to approve posts before they are publicly available.
All Replies
  • Chuck Davenport
    Posted by Chuck Davenport
    on May 02 2012 09:40 AM
    Suggested Answer
    Expert6315 points

    Hello Marco,

    There have been some reported issues with the pull up on nTRST that prevent the device from opperating properly. The issue is specific to the revision of of the device on the HDK board that is currently being shipped. The recommendation is to remove the 10K pull up resistor from the board. This resistor is located on the back side of the board and labeled as R310.

    The schematic for the HDK board is located in the 570 Wiki page at the following location:

    http://processors.wiki.ti.com/images/1/17/TMS570LS31x_HDK_Schematics.pdf

    If this resolves your issue, please indicate by verifying the answer.

    Thank you,

    Chuck Davenport

    Thanks and Regards,

    Chuck Davenport


    If this response answers your question, please indicate it by verifying the suggested answer when provided.

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Haixiao Weng
    Posted by Haixiao Weng
    on May 02 2012 10:57 AM
    Genius9535 points

    Can you check if HET11 is configurated as input, pull disabled, and pull select as 'pull down'? If this is the case, then we can explain why it works in debug mode and not in standalone mode.

    Regards,

    Haixiao

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Marco Moreno
    Posted by Marco Moreno
    on May 02 2012 11:54 AM
    Intellectual300 points

    Haixiao,

    Yes, it looks that way.  Bit 11 in the HETDIR register is 0, in HETPULDIS it is 1, in HETPSL it is 0.  How is the debug vs standalone behavior explained?

    Thanks,

    Marco

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Chuck Davenport
    Posted by Chuck Davenport
    on May 02 2012 13:37 PM
    Verified Answer
    Verified by Marco Moreno
    Expert6315 points

    Marco:

    I believe this is your issue. When the combination of DIR, PULDIS and PSL are set in this way, the input buffer is disabled. See the table below that shows the behaviors for different combinations of these settings.

    The reason why this works during debug mode is that all inputs are enabled and cannot be disabled during debug mode regardless of the settings within these registers. To fix you problem, I would suggest setting the HETPSL = 1 which will allow the input buffer to always be enabled but will not impact the actual pull since it is disabled through the HETPULDIS setting.

    Please let me know if this resolves your issue by verifying this answer.

    Regards,

    Chuck Davenport

    Thanks and Regards,

    Chuck Davenport


    If this response answers your question, please indicate it by verifying the suggested answer when provided.

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Chuck Davenport
    Posted by Chuck Davenport
    on May 02 2012 13:39 PM
    Expert6315 points

    Marco,

    My apologies, but the table did not post for some reason. Please reference table 19-9 in the TRM (SPNU499.PDF).

    Regards,
    Chuck D.

    Thanks and Regards,

    Chuck Davenport


    If this response answers your question, please indicate it by verifying the suggested answer when provided.

    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