LM3S9D96: A few Microcontrollers is not work when it did cold reset for 2000ms.

From the various 'screen-caps' - it appears that the MCU's Reset is NOT being derived from a 'Pull-Up Resistor' tied to VDD.     Instead - a separate 'MCU Supervisor IC' is suspected.    Is this correct?

If so - might that, 'MCU Supervisor IC' deserve (some) scrutiny?     The simple act of (temporarily) disabling that "Supervisor's Connection" to MCU's Reset - replacing that with a pull-up R to VDD - should provide an excellent comparison.     If - the MCU (then) behaves properly - under this new condition - then the 'Supervisor IC' is deemed 'the issue.'

You must insure that the:

• MCU
• your (suspected) Voltage Supervisor IC
• and 'ALL OTHER board components' - when 'COLD' - remain w/in their Operating  Spec.     (you've not defined what constitutes, 'cold.')    

The MCU  (may)  be exclusively  'at fault'  - yet that remains ...  far from proven...

Hello cb1,

Thank you for your advice.

As you said, Microcontroller is connected to Supervisory Circuit which is open-drain.

When it's RESET is open, the RST voltage is over 3.0V.

Although I disconnected Supervisory Circuit, this issue didn't solved.

Below images is the signal on restart w/o Supervisory Circuit.

1 (yellow) : VDD
2 (blue) : RST~
3 (Magenta) : PA1/U0TX

Failed pattern: power off for 2000ms

Succeed pattern: power off for 1000ms

On other hands,

my "cold reset" means restarting with power off like "cold boot".

Best Regards,

Thank you for once again providing those clarifying 'screen-caps' (taken almost exactly - 2 minutes apart.)       They prove highly useful - yet questions (and observations) remain:

• You report 'Reset is Open' - usually that suggests 'NO Connection' to Reset.     Instead - have you not connected a 'pull-up R' to MCU's Reset?     (required for Reset to rise to ~3V.)
• All scope traces (first post & today's) monitor the 'Serial Line Driver's Output' - not that of the  MCU.    To  more 'conclusively'  - blame the 'lost output' upon the MCU - monitoring the MCU's 'UART_TX' output - rather than the 'downstream'  line-driver's output - proves more direct - thus more compelling.
• Past scope traces revealed (imho) an 'improper' decay of VDD!     Rather than 'monotonically' decreasing - VDD showed 'hills & valleys.'    Usually that's judged sub-optimal - and may result from a 'bouncing power On/Off switch.'    That same strange decay of VDD was noted upon (both) your 1000 & 2000mS conditions - yet still (to my mind) deserves attention.    MCUs especially - may be 'individually sensitive' to such 'illegally transitioning'  - VDD power 'events!'
• While you have presented (both) Failing & Passing Scope Caps (from the SAME board) - as this issue is 'Board Based' (occurs ONLY upon a few boards) would not identical scope caps - set to the 2000mS (failure inducing) Power Off duration - but  INSTEAD   taken from (both) a GOOD BOARD (passes your 2000mS test) and FAILING BOARD - prove (even) more valuable/insightful?    

This (now) is a 'bit' of a 'nit-pick' (somewhat arbitrary point) - yet  a  deep 'comparison & contrast' (my group is NOT lazy)  of your  first posting - revealed a 'Non-Linear' relationship between the TWO 'Power OFF durations' - which were listed (first) as 2000mS - and later as 1000mS.     You employed 'Magnification of the 4mS time scale - broadening that to 200mS - in each case.'    That suggests that the 'time off'  (VDD - yellow trace) for the 2000mS (failing test) should be, 'Twice as wide as that of the 1000mS (passing test.)     Yet - our measure (via ruler placed against our Monitor) revealed ~7.6cm (for the 1000mS OFF) and ~26cm (for the 2000mS OFF!)     While admittedly 'crude' - should the measurements NOT have yielded a (near) 2:1 ratio?    (our ratio was ~3.4:1)      This may suggest some error in set-up - or calculation - may or may not - have merit.    Yet a 'good investigator' is 'chartered to report 'ALL Findings' - and not 'Judge their Validity/Importance.'     (I'm only 'sometimes' guilty - of violating that rule...)

It is believed that this NEW request: 

• for new scope caps - achieved from (both) Passing & Failing BOARDS (both set to the 2000mS (FAILING) condition
• AND Ch. 3's scope probe connection - moved to UART_TX (NOT to the line driver's output)

may well prove worthwhile...   (at minimum - will provide (some) diagnostic (causal-nexus) elimination)

Seriously fans ... Where IS the "LIKE" button?     Thanks to the vendor agent - who provides 'substantial' guidance - to so many.     (to include this reporter...)

Sorry for the late reply.

I get signal of Microcontroller's UART_TX and confirmed passed board and failed board again.
Below images are signal of Passed vs Failed.

Passed Board: power off for 2000ms

1 (yellow) : VDD
2 (blue) : RST~
3 (Magenta) : UART_TX

Failed Board: power off for 2000ms

1 (yellow) : VDD
2 (blue) : RST~
3 (Magenta) : UART_TX

At the same time, I compared the duration of power off.
Although 2000ms come from sequence setting of Programable Power Source, the actual duration of power off is short than 2000ms because our product have Power Board which have Electrolytic Capacitor.

Although, there is different about the duration between passed board and failed board.
(*using same Power Board in this investigation.)

Power off duration of passed board: 1867ms (a - b).

Power off duration of failed board: 1479ms (a - b).

In addition,

• The actual duration is 427ms when this board worked at 1000ms power off.
• This board didn't work if the duration of power off is set 2400ms. (actual duration is 1895ms)

------

Our question,

• Is there a specification of the duration of power off at this Microcontroller?
• Is it likely that charges remain inside the Microcontroller even if the external power supply is turned off?

Please let me know if you need any further information.
Best Regards.

Thank you - while you've addressed (only) Ralph - those proposed ' key diagnostic tests/aids'  were mine - justifying my response.

Good to receive your 'clarification' - your earlier (and repeated) reports - of  '2000 & 1000mS 'Power-Off Durations' -  which were (only) 'approximations'  (yet NOT so stated!)      And earlier detected via 'close review' of  your scope-caps - by crack (yet non-vendor) staff.    Usually the 'somewhat precise' definition of  'Failure Conditions' - is required to achieve (both) the fastest & most in-depth - remote diagnosis.

We note that your new caps - while addressing (importantly) the difference in response between (my requested)  'Passed vs. Failed' boards - reveal 'inconsistency of the trigger point settings' - which complicates analysis.     And - in fact - may prevent the 'view' of key/critical 'portions' of the captured waveform.    In clarification - those inconsistent trigger point settings - are (now/here) presented (in line - for eased comparison/recognition) - below:

Earlier the MCU's Reset line was listed as 'Open' (which suggests 'floating or isolated/disconnected') - we cannot believe that statement to be true.    (as Reset rose quickly - some 'connection' to VDD must have existed!)    Clarification - again requested.

In addition - the 'unusual' decay of VDD - was past noted.    Can this be explained?    it proves unlikely that an electrolytic capacitor (alone) would introduce the (notable) 'Hills & Valleys' - upon VDD's (expected) monotonic Decay.

As an independent firm - we defer to the vendor - the response to your request for specification of  MCU's 'Power-OFF's duration.'     (although - those 'hills/valleys' - past (and again) noted upon VDD during Power OFF - may NOT be 'well appreciated'  by the MCU.    (or any vendor's MCU - I believe...)    

Usually - a 'Slow RISE and Faster DECAY' of an MCU's (active low) Reset - overcomes such 'Power ON/OFF issues.'     Use of an external  'MCU Supervisor' - again (my firm detected - as present w/in your design) proves (usually)  sufficient to 'Eliminate such 'Power ON/OFF issues.'  

It has been - well and long noted - that most all of poster's boards - operate correctly!    A 'saving - yet again 'REACH'ed'  (short delay)' - appears NOT too effective!)

Hello cb1,

Sorry for inconvinience.

Regarding following comments at previous my report.

- "As you said, Microcontroller is connected to Supervisory Circuit which is open-drain. When it's RESET is open, the RST voltage is over 3.0V."

"RESET" above meant Supervisory Circuit's reset terminal which is open-drain, "RST" meant Microcontroller's reset terminal.
There is external pull-up circuit of open-drain between Supervisory Circuit's Reset terminal and Microcontroller's RST terminal on our product. (I forgot to inform you that open-drain have external pull-up circuit.)
Therefore, when Supervisory Circuit's RESET is high (=open), the Microcontroller's RST terminal have over 3.0V by external pull-up.

In the investigate, as you requested, I connected only pull-up circuit to Microcontroller's RST terminal by isolating Supervisory Circuit's RESET terminal.

>In addition - the 'unusual' decay of VDD - was past noted.    Can this be explained?  
I don't have found this reason yet. We will investigate it.

Best Regards.

If I may - the 'Irregular Decay of VDD' indeed deserves your attention.     Most all MCUs prove 'sensitive' to such 'VDD Excursions' - especially if they are 'brief' - and pass through an MCU's critical, 'Voltage Inflection Points.'     (those voltage levels- at which the MCU transitions to 'Brown-Out' or 'at/around' the MCU's 'minimum operating voltage' or other MCU operations.)

Rather than an 'UNSPECIFIED UART delay' - a   ' FULL Peripheral Reset of that UART' - which is then 'Tested' (awaits the UART's Signaling it's 'BEING READY') - proves far superior!    (Crude (unspecified) 'delay'  is (properly) replaced - by a  VASTLY  MORE  'Active/Encompassing/Robust' -  UART-PREPARATORY  mechanism!)     [Just what the 'MCU Doctor' ordered - most  here would believe...]

ONLY THEN (upon 'that' UART's 'signaling of ready') does full/proper initialization of that (currently troubling)  UART begin!

In this manner - you have 'BEST GIVEN'  'that' UART - every chance to succeed...   (Failed UART Initialization - to my mind - is your  PRIME SUSPECT!)

user5759918 said:

we are investigating the reason why the UART don't work well

Perhaps PLL or MOSC start up at incorrect frequency, VDD at lower value as FIFO serial frame seems present in scope captures. Couldn't hurt to probe the XTAL after POR test when VDD lowers.

Hello cb1,

we tried to smooth the VDD on power off by direct to supply DC power to microcontroller board.

[ Circuit configuration of our microcontroller board: 12V input -> Voltage Regulator -> 3.3V -> Microcontroller ]

we succeeded to smooth it but this issue still be occurred. Below image shows VDD decrease at the time.

1 (yellow) is 12V supply to microcontroller board.
2 (blue) is 3.3V supply to VDD.

On the other hand,
We dicided to replace this microcontroller on this failed board, so we might not be able to get signals anymore.

I will inform here if there is any progress.

Thank you.

Thank you for (another) detailed update - your newest waveforms are much more 'conforming' ... thus comforting.

user5759918 said:

We decided to replace this micro-controller on this failed board

Ouch!    While that MCU Replacement 'is' understandable - it removes the opportunity to,  'Launch further attempts - to glean understanding - and effect a (real) cure!    (i.e. You've removed staff's 'fun.')   Really!

Note too: Staff's  (eagle eye) detects that your particular MCU is 'dead/buried' ... thus MCU Replacement has: 1) eliminated further test/discovery; and 2) further depleted  your (assumed) small/shrinking inventory - of an 'EOL' device - thus (almost) 'irreplaceable!'    

It proves (especially) unfortunate - that the 'last proposed code change' (Ordering the UART into Peripheral Reset - and (only) after that successfully completes (UART becomes 'ready')  then proceeding w/ full/proper UART Initialization.

Indeed you need to ship, 'Properly Performing Boards' - yet as the 'Issue's Source' has not (yet) been unmasked - what's to be done - 'should' (or more likely WHEN)  that issue - revisits?      And that - remains as high -  'cause for concern'...

Hello TI Engineer,

We found below Errata. Is it relate to this issue?

- Stellaris® LM3S9B96 RevB1 Errata
2.6 "Internal reset supervisors may not prevent incorrect device operation during power transitions"

We looked back our signal capture, it is seems that failed board don't meet below conditions on the Errata.

• 3. The power-down transition of VDD between 3.0 V and 1.5 V must not have any points where it increases in voltage (must be monotonic).
• 4. Once steady-state operation between 3.0 V and 3.6 V is achieved, RST must go Low or the CPU execution must be halted prior to VDD falling below 3.0 V.

We believe LM3S9D96 also have this reset issue same as LM3S9B96.
Can you investigate which this MCU also have this reset issue?

Best Regards.