• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 84 subscribers
  • Views 609 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.

TMS320F28027F: Intermittent Processor Resets occurring every 4-6 hours

Peter Davis1
Intellectual 440 points

Part Number: TMS320F28027F
Other Parts Discussed in Thread: TPS62135

We're using a TMS320F28027F on a custom board and are seeing intermittent processor resets once every 4-6hours. The watchdog module is disabled in HAL_init but Brown-out Protection is enabled (by default). We are not using the internal VREG, so we have VREGENZ_Bar pull high. We know the software is resetting by sending a UART message on initialization. Can anyone provide more insight into the following questions:
1) Other than BOR, POR and watchdog resets, is there another way to reset the chip?
2) What is the trip point for a power-on reset?
3) Is there a way to distinguish between the BOR and POR?
4) Could you provide more details on the behavior of the BOR? The datasheet indicates that the trip point ranges between 2.42-3.135V (2.65V typical) but the Silicon Errata shows that "if the full operating range is utilized, random resets may occur". Is there any more detail on? The datasheet also specifies a 35mV hysteresis could you expand on how that is used in the reset behavior?
5) We disabled BOR and during our testing found that the XRS_BAR is asserted for ~600us when VDDIO drops to 2.6V, is this expected behavior?
Thank you,
  • 0
    TI__Mastermind 30571 points

    Hello,

    A subject-matter expert will reply your question. However, we have been dealing with inclement weather and power outages in the area and responses may be slow.

  • 0 in reply to Gus Martinez
    TI__Guru* 86060 points

    Peter,

    1) Other than BOR, POR and watchdog resets, is there another way to reset the chip?
    A1)No, these are the only reset sources on the device.  Expanding a bit on the below, if its not the POR/BOR(I'll clarify how to tell this) then its the WD which could be related to your code getting stuck unexpectedly.
    A2-A5)

    If the internal POR/BOR module detects a threshold violation it will pull the XRSn line for the ~600us you observe.  So that is to say if you see a reset pulse of this duration on XRSn it is that module that has driven it for debug purposes(not sure if you would have captured this on the 4-6 hour failures)

    The POR/BOR on this device can be thought of more as a "coarse" detection(POR) and "fine" detection (BOR).  When the device powers up initially the POR will be active immediately and will release reset in the 2.4-2.6V range as you observe.  In parallel the "fine" detection circuitry of the BOR is powering up/stabilizing to provide a tighter limit to the operational range of the device.  This will come online prior to the 600us XRSn hold, so that if the VDDIO voltage is still below 2.42-3.135V range it will hold reset until the voltage has exceeded that amount.

    In a typical use case 600us after the 2.4-2.6V range the bus voltage will be in range for the BOR  for proper operation so XRSn will release without more delay.

    The errata note on operational range impact, is caused by the fact that the device itself is capable of operating with a 10% tolerance on its supplies, so 2.97V-3.63V on VDDIO is acceptable.  The reason we have an errata is that we have seen the BOR detection threshold on some devices reach as high as 3.135V.  So that if a customer was regulating in the 3.0V-3.135V region the BOR could still cause a XRSn event which would be undesirable.  A workaround here is to disable the BOR, which will drop the detection threshold to 2.4-2.6V range as you observed.  The downside of this is that the device could be operating out of spec for longer before the POR trips XRSn.

    As a debug step you could keep the BOR disable in your code, and see if the system doesn't reset after 4-6hrs.  This would mean, however, that the device did observe an event in the prior iteration so you may want to better understand that from a system POV.

    The hysteresis is there so that if XRSn is released and the voltage droops a bit we don't pull low immediately/unnecessarily.  To clarify a different point, the release of XRSn has a 600us delay, the drive of XRSn low is immediate once the voltage trips the threshold(+/- the hysteresis).

    Let me know if you have more questions.

    Best regards,

    Matthew

  • 0 in reply to MatthewPate
    Intellectual 440 points

    Thanks Matthew, we have confirmed it was due to the BOR limit.

  • 0 in reply to Peter Davis1
    Prodigy 20 points

    Hi Matthew,

    I'm working with Peter on this issue and have a follow-up question. We are noticing that disabling BOR improves our performance by halving the number of failures that occur. One path we are exploring is disconnecting the XRSn pin from our board through rework. My questions are:

    1) Is there an internal pullup that can be enabled on XRSn?

    2) If yes, can it be enabled during bootup as well?

    Thanks,
    Aditya

  • 0 in reply to Aditya Kodkany
    TI__Guru* 95315 points

    1) Is there an internal pullup that can be enabled on XRSn?

    Yes (as mentioned in the datasheet), although it is a weak pull-up.

     

    2) If yes, can it be enabled during bootup as well?

    It cannot be disabled.

     

    See https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/826349 for additional perspective on the -XRS pin.

     

  • 0 in reply to Hareesh Janakiraman
    Intellectual 440 points

    Since there is a weak pull-up internal to the IC, is it acceptable to leave this pin floating on the IC if we don't plan on connecting external circuitry to assert the Reset line?

  • 0 in reply to Peter Davis1
    TI__Guru* 86060 points

    Peter,

    Is the concern that you've got noise coupling from the PCB onto the XRSn pin causing low pulses?

    Can you comment on what the pin was connected to on the PCB previously?  Was it an on board PU(10k to VDDIO)?

    If the above were true then relying on the internal PU(300uA) and then floating the pin might be a simpler option than trying to isolate the noise or add some capacitance to filter it.  

    This is not something we usually recommend, but trying to be a bit flexible depending on what you feel the root cause is. 

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Intellectual 440 points

    Matthew previously,
    We were connecting the Power good of a TPS62135 to the XRS line with a 10k pull-up to VDDIO and 4.7nF filter capacitor. We are using this MCU to run a motor and in addition, the 3.3V rail that powers the MCU (VDDIO) it also supplies power to a 1.8A load that switches at 45Hz.

    We believe we are getting false failures on the PGOOD line of the TPS52135, which causes the MCU to reset, in addition to the BOR issue that we have since disabled per your last message. In order to simplify the design we would like to isolate the XRS Pin from any additional circuitry and rely only on the internal pull-up.

    Can we leave the reset line floating, to ensure this does not occur? Are there any risks in doing that?

    Here is our current schematic design (Power Good is connected to XRS) Ignore variance in net name:

  • 0 in reply to Peter Davis1
    TI__Guru* 86060 points

    Peter,

    If it gives the same performance I would prefer just lifting the PG pin of the TPS so that it is not driving the XRSn pin.  This would leave the 10k PU to give a stronger drive.  If this the TPS is a QFN(leadless) could we cut the trace on the board to decouple these signals?  

    However, if you know there is additional noise coming in on this path(even without the PG pin present) or the PG can't be removed then I agree that it is a better option to float the XRSn pin and rely on the internal PU in this case.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Intellectual 440 points

    Matthew,

    The TPS is a QFN and we cannot cut the trace, can you confirm there is no risk in floating the XRSn pin and relying on the internal pull-up. I need to ensure this is a reliable change across multiple units?

  • 0 in reply to Peter Davis1
    TI__Guru* 86060 points

    Peter, 

    Let me consult with a few more team members on this.  Will try and reply by tomm EOD.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Intellectual 440 points

    Thank you Matthew, I appreciate your quick replies and assistance with this debug effort. Getting a conclusive answer by EOD tomorrow would be extremely helpful. Our PCBA build has already been delayed a week due to the issues we have been seeing with this failure, and we need to start the build by Monday. If we can lock down that this change is acceptable by tomorrow that will unblock our build fully.

    Peter

  • 0 in reply to Peter Davis1
    TI__Guru* 95315 points

    Peter,

    Reading through the thread, I am still not clear what is causing the voltage to sag (and reset the device) in the first place. You say "We are noticing that disabling BOR improves our performance by halving the number of failures that occur." So, even disabling the BOR does not eliminate the problem. So I don't understand how disconnecting -XRS pin is going to help. I wonder if the "false failures on the PGOOD line of the TPS52135," is actually telling us something. Have you measured the ripple on the supply lines? Specifically, triggering the scope when the supply dips below a particular value? You mentioned you cannot cut the trace, so do you plan on redesigning the board? If so, you could retain the R-C circuit on -XRS instead of floating the pin.

    My concern is this: If we float -XRS without having clearly identified what is causing the resets (even after disabling the BOR), the problem may not be solved even with the new design.

  • 0 in reply to Hareesh Janakiraman
    Intellectual 440 points

    Hareesh,

    We have already prototyped the modification and verified that we get no resets when disconnected from the Power Good signal of the regulator. We have drafted rework and are about to execute it. Our question is very specific:

    • Is there a reason why we would need an external pullup on XRS?
    • We have measured the voltage on the open XRS pin at 3.28V with VCC at 3.30V. This clearly satisfies a logic high level, yet the data sheet indicates a need for a 2.2k to 10k external resistor. Is this external resistor necessary?

  • 0 in reply to Peter Davis1
    TI__Guru* 95315 points

    We have measured the voltage on the open XRS pin at 3.28V with VCC at 3.30V. This clearly satisfies a logic high level, yet the data sheet indicates a need for a 2.2k to 10k external resistor. Is this external resistor necessary

    The datasheet suggests the external resistor because the internal pull-up is a weak PU. Understand it satisfies the logic level, but what needs to be determined is whether it would be adequate to hold the -XRS pin high under all operating conditions (when the system would be subjected to noise). Perhaps I am missing something but if you are going to redesign the board (to remove the PG connection to the -XRS pin), why not retain the R-C circuit on the -XRS pin? If extensive testing shows that these components are unnecessary, you could choose not to populate them.