• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 736 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS570LS3137: Certain IO pins drive high on reset

Greg Baghdikian
Prodigy 155 points

Part Number: TMS570LS3137

Hi,

I am working with a TMS570HDK that contains a TMS570LS3137ZWT. I've noticed that, even though I've configured the pin (in this particular case, Ball M17) to be muxed as RTP_DATA[7], and have disabled the pullup/pulldown, AND removed the external pullup from the HDK (R32), the MCU drives pin output high a couple times within a millisecond or so (scope shot is below). After this, I assume the firmware has ran long enough for the pinmux to be set to RTP_DATA[7] and it finally gets pulled low due to the external 10k pulldown I added.

The second test I ran was with the TMS570's flash completely erased (so that the pinmux wouldn't be set). After pressing the RST or PORRST button, the pin continues to drive high until a RST button is pressed again.

My expectation was that all IO pins would be set to Input by default and therefore would not produce voltage spikes, but this doesn't seem to be the case.

Is there an explanation for this behavior and how to remedy this problem?

My setup:

  • 0
    Prodigy 155 points

    My modifications to the HDK: 

  • 0 in reply to Greg Baghdikian
    TI__Mastermind 49120 points

    Hello,

    The default function on this pin is EMIF_nCS[4] which is an output function. So this terminal is driven as output High (inactive chip-select) as soon as the system reset is released. It becomes an RTP_DATA[7] terminal once your software switches the output multiplexor. The RTP module configures this terminal as a general-purpose input as a result of the default states of the RTPPC1 register fields.

    This issue was considered and addressed for EMIF output signals ( EMIF_ADDR[0], EMIF_ADDR[1], EMIF_ADDR[6], EMIF_ADDR[7], EMIF_ADDR[8], EMIF_BA[1], EMIF_nCS[0], EMIF_nCS[3]) multiplexed with other functions such as N2HET signals, where the outputs are not enabled by default and requires the software to enable these outputs. However, the EMIF/RTP terminals were excluded from this. The issue only occurs for this particular EMIF_nCS[4]/RTP_DATA[7] terminal mainly because the EMIF module drives a High as a default output state. All other EMIF/RTP terminals are driven output low (which could be an issue in applications expecting an external pull-up to hold the terminal High.

    I do not see a way to work around this.

  • 0 in reply to Sunil Oak
    Prodigy 20 points

    Thank you for the reply

    1. Are there any other pins on the device that could exhibit this same behavior? Is there any documentation describing this? This pin's behavior goes against documentation. The documentation says output-only pins have their buffers disabled, which should still allow for external pulldown if I understand this correctly. 
    2. When the MCU is powered on (coming out of POR) various other IOs have the same behavior, but not on warm reset. I assume these are other "output only pins". This seems very wrong on a safety MCU to have pins act differently in different states unpredictably. 

  • 0 in reply to Julian Shur
    TI__Mastermind 49120 points

    The documentation says this for default output functions:

    " All output-only signals have the output buffer disabled and the default pull enabled while nPORRST is low, and are configured as outputs with the pulls disabled immediately after nPORRST goes High."

    So as soon as the power-on-reset is released these terminals are controlled by the default function, which is an output in case of EMIF_nCS[4]. There are other terminals that have EMIF/RTP signals multiplexed on them:

    Of the above terminals, those highlighted with the blue box have their default outputs disabled assuming that you could have these configured as general-purpose I/Os connected to N2HETx functions. The other terminals in the above list will be driven output as EMIF functions once reset is released (a mistake in the definition on hindsight since RTP signals can be used as general-purpose I/Os as well).

    The M17 terminal is unique in the above list in that it will be driven output High. The other enabled outputs drive Low once reset is released and until software programs the output multiplexors.

  • 0 in reply to Sunil Oak
    Prodigy 155 points

    Thanks for the quick responses. We wish the documentation was more clear but we now have a better idea which pins we can use for our application.

  • 0 in reply to Sunil Oak
    Prodigy 155 points

    Where in the manual does it specify the default output? Do we look at the IOMM section for that?

  • 0 in reply to Greg Baghdikian
    TI__Mastermind 49120 points

    The default outputs from the EMIF module are:

    CKE=ADDR=DQM=0

    nCS[0,2,3,4]=nRAS=nCAS=nWE=BA=1

    DATA=HiZ

    These are the inactive states of the EMIF signals ('1' for active-low signals and '0' for the others). DATA is bidirectional and is tri-stated (input) by default.

  • 0 in reply to Sunil Oak
    Prodigy 20 points

    We see some similar bliping behavior on POR with balls C9, C17 as well. 

    I see blipping during warm reset but not POR on ball C8.

    It seems like the EMIF/RTP pins don't behave well during resets in general, at least according to your information and whats described in the datasheet.

  • 0 in reply to Julian Shur
    TI__Mastermind 49120 points

    Julian,

    I will look into these EMIF/RTP signal default states and get back to you.