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.

TM4C123GE6PZ: Device STOP WORK Issue

Part Number: TM4C123GE6PZ

I need help for a very urgent case about M4 in Customer Product.

 

Customer found their product will totally stop working if put strong EMI source close to the M4 device for a while (around 1 hours), in this case, M4 all pin function stop working forever without any respond.  (it means even watchdog donot work to reset)

Unless device external reset or power on again, it resume to work. (it means device is not damage and internal code is safety)

 

We double confirm the watchdog function by remove the “Clear Dog” code then run customer product in normal environment,  M4 will be reset by watchdog.  (it mean watchdog code should be not problem, however watchdog just do not work when device in stop working issue)

 

We want to know which possible reasons could cause M4 Totally Stop Working even watchdog is also not functions.

Wish get help some advice today, because We are required to do the test and confirm the root case by tomorrow.

Because TOP End-Market report such issue, it give very bad affection to customer and they pay much attention on this case.

  • Have you looked at the errata? There is an errata on rapid edges that could apply.

    Robert
  • Hi Robert

    Yes, I check the all errata.

    Do you mean the GPIO#10 about the rapid edges issue? The item description the issue will causing a high current draw, does it will let Device Stop Working? If yes, what the principle is?

    actually, I notice HIB#03, MEM#04, MEM#05 issue description will causing device not working, however customer application do not use HIB and EEPROM function, so should not affected by such issue.

    I cannot find others errata items description about Device Stop Working, could you help advice more detail? thanks
  • That's probably the one I was think of. I didn't recall the exact affect.

    Since it latches the pins until power is cycled then a watchdog reset might not be noticed even if it occurs since the processor can no longer control the I/O. Of course if they are latched for any significant period of time it might just destroy the chip.

    Your corporate compatriots might have more details available.

    Robert
  • Terry Deng said:
    ...product will totally stop working if put strong EMI source close to the M4 device for awhile

    Should it not be asked:

    • does this issue persist across (many) client boards?
    • how legitimate is: a) the strong EMI source, b) the separation distance between MCU & EMI source.     Is the EMI source being placed according to "normal/customary" specification?
    • if there exists any "doubt" as to legitimacy or "recent" calibration of such EMI source - should not a "different" such source be acquired - and tests (then) repeated?
    • is the EMI source being separately/independently powered from the MCU?    It is unlikely that such "exact" source - and the MCU - will run from the "same" power source in "real-world" operation.
    • has "very urgent" client's board designer placed (similar) "very urgent" review & regard upon the many - vendor supplied - board layout & design guides - which may enhance resistance to EMI?
    • has client attempted a (near) identical test upon (other) MCU boards (such as LaunchPad) - and compared the incidence of this issue?     Adds much value/insight - does it not?

    Performing such detailed tests - and confirming "root cause" - w/in one day - borders upon the "unreasonable" and leads to the (fair) question, "Why was such discovery made SO LATE by client w/in the design process?     The note of  "very bad affection"  may (more properly) fall upon this client - it is not (always & only) the vendor who proves, "at fault."

  • CB

    The customer board has run on the market for around 2 years with large quantity, in the design phase, the board are reviewed by TI and also pass customer EMI/EMC test standard. The STOP WORK issue is feedback from after market recently, and we really recur such issue in the lab by put 2 GPRS module (as the EMI Source) nearby the device (10cm distance).

    We try run the device with TI simple sample code which just enable watchdog and toggle a GPIO, and device still will STOP WORK forever (after run around 2 hours ) in GPRS test environment. so we think it is not SW issue but HW related.

    Customer agree the issue should be caused by EMI, although we cannot clear know how larger noise in the after market user environment. However customer cannot understand why device will STOP WORK, they think at least device should be reset by watchdog on the strong EMI environment.

    We want get help here is that what all possibility analyze from chip internal point that will cause M4 STOP WORK? So that we can arrange tests according one by one to identify the root cause and design improve method.

  • Terry Deng said:
    we really recur such issue in the lab by put 2 GPRS module (as the EMI Source) nearby the device (10cm distance).

    This method of, "EMI testing"  seems outside of, "normal/customary."     How do you know that the "field strength" of each GPRS module is "proper" - and does that 10 cm "separation distance" meet (any) known EMI test standard?      It is known that in both "defense" and "medical" industry - such tests are defined & described - and would NOT be left to (random) GPRS modules.

    You've not answered the request to learn the, "Frequency of this issue" - that's of critical importance - is it not?       The direction of such testing much depends upon the, "Percent of Failing Units" - and in addition the ability to perform, "A-B comparisons" (via "Pass vs. Failed" units) proves (usually) of huge value.     Again that request for the "Extent of such failures" has NOT been provided!

    Once you've acquired a reasonable number of such "issue-laden" boards - should not those be inspected for MCU date codes - and for their proper assembly.    MCU's reset line should be short & direct - as should be the (many) capacitors which bypass the MCU's power pins - and especially those connecting to VDDC.    (I'd use a "C meter" to insure that the specified capacitor value @ VDDC pins has been well met.)

    I believe the great interest in "STOP WORK" must prove second to the,  "Establishment of a more, "conforming EMI test" - performed w/proper, focused equipment - designed specifically for that role - and recently/properly calibrated!

  • we know our EMI test method is not normal and standard, we just try to recur and confirm "STOP WORK" issue really will happen, we have do test on 4 pcs product and all 4 product can 100% recur the issue.

    what customer feel strange is that why device will not reset by watchdog but STOP WORK forever? In normal idea, we think the device should either reset or damage if it affect by strong EMI (even by not proper test).

    so we just want double confirm in here whether device really will "STOP WORK" on some condition. If yes, what all possibility condition they are. If no, how to explain our test result? 

  • I would characterize 4 pcs as, "far too small" - and these may have been "cherry picked" by client. (i.e. client gave you "failed units" - to place the onus of repair upon you!)

    Still unanswered - and still VITAL - what is the percent of units which are failing this "Non conforming" test?

    Note that my firm had a brand new "cable modem" (for our firm's high speed internet) and it, "Knocked out every radio w/in our shop!" We replaced it - (gaining some improvement) - and replaced it again - and (now) all radios are (again) interference-free! Thus - certain devices are "known/confirmed" EMI/RFI "OFFENDERS" - and may cause a "proper system" to misbehave.

    To issue "STOP WORK" - when such "Non-Standard, EMI Test" is performed - and demand a "Next Day" resolution - reveals a (possible) "Lack of reasonableness" from such party...