• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 28 subscribers
  • Views 487 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C123BE6PZ does not power on in test fixture with relay controlling power

John Osen
Genius 3585 points
Other Parts Discussed in Thread: TM4C123BE6PZ

We are testing a TM4C123BE6PZ in a test fixture where the power is cycled for the test via a relay.  The cycling is not rapid (seconds between power cycles).

We are using StellarisWare 2.1 and CCS 5.5.

Although the hibernation peripheral is enabled, hibernation works off of a 100msec debounced input, so the power drops before hibernation can be requested.  An errata on this subject is not applicable.

The module uses a CAN bus and sends out an identification message on power up.

Sporadically, the controller is non-responsive for a given power on cycle.  A subsequent power cycle will wake the controller up and an identification message is seen.

There does not seem to be anything in the errata that would cover this.

Is there a power cycle mode that can lock the processor on power up?

  • 0
    Guru 47900 points

    Have followed your posts - suspect issue is not confined to a single board.  (Might you confirm?)

    We've encountered somewhat similar - again when power was relay controlled.  Untold, unknown is that relay's contact conditions, "snubbing," and indication of power being transferred.  Have you scoped the power input to your DUT? 

    We past found, corrected by noting a strong relay noise impulse and contact bounce - which appeared to disorder either the MCU or 3V3 regulator - upon power up.  We cured by replacing the relay with power FET driven by standard gate driver IC.  (suggest that you avoid "charge pump" style gate driver - this may output "enfeebled" initial power.)  Instead - employ driver with "always present" & sufficient gate voltage - awaiting just your, "Go" signal command...

    [added] We "caught" our relay issue via data logging:

    a) the relay's output

    b) our on-board 5V "pre-regulator"

    c) and our final, ldo 3V3 regulator

    Relay output contained "hills/valleys" - as a result our 5V reg (switcher) stumbled - and the 3V3 and/or MCU Reset on occasion were disturbed.  (can't recall if we ever "caught" the 3V3 misbehaving - but the switch-over to FET control instantly (and completely) solved this issue.  (build was just under 600 boards - in that instance...)

  • 0 in reply to cb1
    Genius 3585 points

    cb1- said:

    Have followed your posts - suspect issue is not confined to a single board.  (Might you confirm?)

    Spot on suspicion.  Six controllers, all randomly showing the symptom.  300 seconds on, then off (still finding that time), then on 300 seconds.

    I was suspicious of the relay.  I once worked on a thermostat where the relays on the furnace through a hundred+ feet of wire still was able to scramble signals on a board.  In this case fouling writes to an external EE.  So fouling the voltage regulator sounds possible.

    I will pass on  you insight (again of great worth) to our electrical guys.

    Did your findings lead to changes in the target, or just the test fixture?

    Regards.

  • 0 in reply to John Osen
    Guru 47900 points

    John Osen said:
    Did your findings lead to changes in the target, or just the test fixture?

    Our "pre-regulator" came from this vendor - is a 5V switcher which (rather uniquely) accepts 7 - 72V input.  (how is that for input range/flexibility?)  We then have a 2nd switcher (12V) and finally 3V3 ldo (linear, driven by the 5V) which runs the MCU & other low-level/critical. We tweaked the 5V switcher - and that cured the "noisy" relay - just as our switch to the FET-switched power had done. (past post described)

    While sub-optimal as a switch device - your relay (and ours) may provide an extra test and/or indicator of "system robustness" and may thus provide an advantaged "test mechanism" which may confirm the success of each/every of your, "target board power tweaks!"

    Your kind words again appreciated.  The clarity & detail you provide encourages & eases response...

    [added] "x&%@" has yet to, "hit the fan" this morn - so have few more details.  Suspect that your power disturbance issue may be:

    a) relay bounce - causing input voltage transitions beyond your target's ability to reject/function properly

    b) noise spike - either upon relay contact's "make" or upon each contact bounce

    c) magnetic field impulse - able to disrupt your target

    If you're especially unlucky - an insidious, intermittent, "combination" of these 3 gremlins may visit.  (good luck, then!)  Beyond prayer/divine intervention - you may increase the distance between the relay and DUT.  If that's disallowed - creation of a reasonable, magnetic (not ESD) "shield" may comfort. 

    Appears that your relay - rather than being villain - may instead have played the role of, "Canary w/in the coal mine!"  When similar plagued us - we vectored to that field "famed" for "survival under adverse electrical noise conditions" that being automotive electronics.  Recall that SAE has multiple publications well detailing the creation & test of your target's performance under "harsh, real-world" conditions.  Proved very valuable to our small group - bet yours too...

  • 0 in reply to cb1
    Genius 3585 points

    cb1- said:
    While sub-optimal as a switch device - your relay (and ours) may provide an extra test and/or indicator of "system robustness"

    We already have had several discussions on your inputs here.  I very much agree that 'fixing' the test fixture is just reducing the visibility of an inherent defect that will bite at sometime after you go from 40 test units (six being used in our power cycle test) to 4000 units shipped to the field.

    The voltage supply circuit is the same as on a second controller that does not show the symptom.  I will confirm that the same text procedure/fixture was used.  The problem controllers also have a 802.15.4 wireless module on them that may be hung up through similare voltage supply issues.

    After being stuck for a week, we are now searching in multiple directions.  Thanks.  I will post what we find.

     

  • 0 in reply to John Osen
    Guru 47900 points

    I'm "on the road" net & power both "spotty."

    I added to "just past" post - believe that new writing will prove of interest/value to you...  (i.e. SAE "expert" in such)

  • 0 in reply to cb1
    Genius 3585 points

    I will close this issue off.  

    The issue changed as the environmental chamber dried out, indicating high moisture content had a role.  We also caught enough CAN traffic to show that the relay cycle was causing enough disturbance on the power line as to reset all devices at the same instant in time (one instance in 1 million CAN messages).  In normal running, the test sequence would not allow this in order to avoid a CAN address claim conflict.  So when six units came on line at the same instance, one would win address arbitration and the other five would go into a standby, 'do not speak until spoken to' mode.  I have handed this from a 'probably software issue' back to  the HW guys to determine if the power circuit is robust enough.  This test fixture's test driver did not capture CAN traffic, just test case failures.

    We also looked at the test fixture's CAN wiring topology.  It was very much out of range of recommended drop lengths.