• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 1384 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.

TM4C1294KCPDT Watchdog Doesn't Always Reset after ESD Chassis Ground Bounce

Tom Farmer
Intellectual 765 points

We are having an ESD Immunity compliance issue.  Our PCBA is fully enclosed in a metal chassis. The chassis is connected to earth ground.  The GND of the PCBA within the enclosure is connected to chassis at one point.  If we do a 4 KV direct-contact discharge to the chassis connection to external ground (a wire), the TIVA processor sometimes hangs permanently in a very strange mode even though the watchdog was enabled.  (25-50% of discharges cause this effect)  In other words, the watchdog does not cause the chip to reset even though it seems to be hung.

We have tried enabling both Watchdog1 and Watchdog2 (but not at the same time).  I have confirmed that the watchdog timeout definitely causes a reset under other circumstances so I believe it is being set up correctly.  But after the 4KV discharge, the processor seems to be halted.  We do not use hibernate mode in our application.  When halted; I have verified that the /HIB pin is high both in normal operation and when in the "halted" state.  I have instrumented other parts of my code and everything seems to have stopped.  The 25 MHz signal is definitely running.   If I then manually ground the /RST pin, the device resumes proper operation. 

So, why doesn't the watchdog cause the device to reset?

Device: TM4C1294KCPDTI3

ARM compiler: 5.2.7

TIVAWARE version: 2.1.1.71b

TI-RTOS version:   2.16.0.8

NDK version: 2.25.0.9

  • 0
    TI__Guru**** 244400 points
    Hello Tom

    Thanks for the details. There is a known errata where a fast rising signal may cause IO latch up. In case of the IO latchup the device will sink in very high current. This happens on the PB0 and PB1 IO's of the USB. Are you able to measure the current draw of the device in this faulty state or use a temperature sensor to check the package temperature of the TM4C129x device.
  • 0 in reply to Amit Ashara
    Intellectual 765 points

    Hi Amit,

    I did not see your response until today.

    I do not have a way to measure the current; the device does not seem to be getting any warmer.  I did not see the Errata you refer to in the device Errata sheet currently on the TI.com web page (SPMZ850F dated May 2016).  Can you provide a link to it?

    As for the issue itself, I doubt it is a hardware latch-up related to these ports.  We have implemented an external watchdog that asserts the nRST(pin 70) when the TIVA stops strobing it.  When the external watchdog asserts nRST, the TIVA chip responds to the reset and resumes proper operation including the USB VBUS and ID lines.  If there was a latch-up, wouldn't these signals be stuck internally?  As for the symptoms we see when the failure occurs without the external watchdog enabled, all of the TIVA's TI-RTOS tasks do not run  We can tell this because there are various GPIOs that our tasks toggle when running and all of them are static.  Furthermore, the on-chip watchdog fails to issue a reset; this should be independent of anything happening on the USB pins...

    For now the external watchdog seems to mitigate our problem.  Clearly it is a band-aid because we do not know the root cause.  It would be nice to understand what is happening.

    Regards,

    Tom

  • 0 in reply to Tom Farmer
    TI__Guru**** 244400 points
    Hello Tom

    Following is the link to the errata document

    www.ti.com/.../spmz850f.pdf

    In the case of the latch up of the IO, a device reset recovers the device. Please note that device reset is different from watchdog reset if the watchdog reset behavior has been changed in the SYSCTL.RESBEHAVCTL register. I believe the first level of debug is to check the current consumption. If the device is not getting warmer then perhaps it is not the PB0/PB1 issue as we have clearly seen device warming up uncomfortably.
    Also to be able to understand the issue better, there has to be a specific condition that needs to be isolated at your setup so that we can begin an investigation accordingly,
  • 0 in reply to Amit Ashara
    Intellectual 765 points

    Hi Amit,

    Aside -- In case anyone else follows this thread, I think the errata Amit is referring to is GPIO#09.  I previously did not see it because I was looking in the USB section.  Also, for reference, we are using OTG so we cannot put the resistance in series that is recommended in the system design guidelines for device-only applications.


    The device does not get warm.  Also, the whole chip seems to be completely non-functional so it would not be possible for the firmware to implement the workaround suggested in errata issue GPIO#09.  Anyway, I agree with the conclusion that it is a different issue.

    As for the next step, I don't think there is anything more you can do.  We are repeating our ESD testing with the external watchdog enabled so hopefully we will be able to move onto other projects....

    Regards,

    Tom

  • 0 in reply to Tom Farmer
    TI__Guru**** 244400 points
    Hello Tom

    I personally don't like such an unknown, when the debug is not done for the issue. However considering that you have project to work on, it would be safe to say that while the external watchdog is able to recover the device and allow it work, it should be OK. But if the system still fails we may have to have better understanding of the ESD event.