MOSC Failure Timing

Clearly I've been here too long - but did not you broach this subject in the past?  (6+ months, or so)  I cannot recall any reasonable response/resolution.  (should my hallucinatory meds have dulled - your forum search {MOSC - if not tried} may identify any past efforts).

Should vendor not arrive/rescue - could not some info be gleaned by your deliberately causing the MOSC to fail?  (perhaps a selectively driven, HF xstr - w/it's "open collector" tied to one of the MCU's xtal pins - may cause the failure - and your "delta-time" measurement of the, "Onset of the Reset pulse" thus determines your desired response time.  Maybe...

I don't think I've broached this question before (I just did a quick search but I could have missed something).

I did ask about care and feeding of the watchdogs but that was answered.

Testing might be possible, I'll wait and see if TI responds before I consider whether it will be worth that effort.  Currently it's shaping up to be a belt ans suspenders type of question.

Robert

Hello Robert,

I believe that you are referring to the Errata as well on TM4C123X devices (SYSCTL #03).

I will need to check what is the time it takes from enabling the MOSC to the point it detects that the crystal is not starting at all. Indeed it is a good point that it should have been spec-ed in the electrical section. Thanks for the valuable input (we overlook sometimes the obvious)

Regards

Amit

Here's proof that (not all) forum recollections are hallucinatory: (close but misses your exact issue...)

http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/321553/1157989.aspx#1157989

The (bit) gratuitous use of "sometimes" is memorialized...

Amit Ashara said:

I believe that you are referring to the Errata as well on TM4C123X devices (SYSCTL #03).

Good point, I'd forgotten about that.  I am using both Watchdogs so I should catch that.

Any idea when this is likely to be fixed?

The startup timing would definitely be useful.

We've developed more information on our problem that caused me to raise the question initially.  We appear to be getting brown out resets from induced noise so we are tracking that further.

Robert

Hello Robert,

Is the regulator output current sufficient to power all devices on board? The BOR threshold on TM4C123 is very close to the MIN VDD supply rail rating.

Regards

Amit

I believe the power supply is more than sufficient Amit.  Bench tests show no pertubation on 3V3 even at full load (or with step load changes).

In addition rerouting cables and adding ferrites reduces the problem significantly (Maybe to zero). 

This leads to to the conclusion it's likely noise pickup and we can see significant noise on an I/O line we are monitoring preceding the reset, it just doesn't always cause a reset.

We need to do more investigation before we settle on a solution or solutions.

Robert

Amit Ashara said:

The BOR threshold on TM4C123 is very close to the MIN VDD supply rail rating.

Ouch - that's not exactly normal/customary - is it?

Indeed - the 3V3 supply should be sufficiently robust to escape such BOR episodes - but declining input voltage to that 3V3 regulator (or ones likely regulating to higher V - before it) may cause transient drops which yield unwanted, BOR triggers.

Is there any explanation as to why the BOR threshold so closely approaches MIN VDD?  (and might that be scheduled for future review/adjustment?)

Hello cb1_mobile

I think a similar post was there a few weeks back where connecting JTAG to TM4C123 was failing and it turned out the the VDD was dropping too close to the BOR level. It has been adjusted well for TM4C129 devices since then.

Regards

Amit

I didn't notice the BOR levels being especially an issue.  We have an external supervisory circuit (which BTW does not trigger) with similar thresholds.

On first blush it would appear the external supervisory circuit is more tolerant of noise glitches than the internal microprocessor circuit.

Robert

Would it not be helpful to compare poster's MCU's BOR threshold & MIN VDD "delta" vs. most other MCUs - here? 

Amit - your writing suggests that poster's "delta" (w/his specific MCU) is less than normal/customary - if I read/absorbed correctly.  Depending upon the application - such may be either good or bad.  Yet - poster's statement that his MCU supervisor has a greater "delta" than the MCU in question serves as further proof that poster's MCU's BOR threshold may lead to unwanted/nuisance BOR triggering.  

Should that be a general concern?  Why does the BOR threshold differ from other MCUs here - should that be the case?  (which earlier writing strongly suggests)  (clients noted - pressed me to detail)

Just for further information

The external SVC we are using is an APX803-31SAG (nominal trip at 3V08, range 3V04 to 3V13).

BOR on the micro is nominally 3.02 and 2.92 with ranges of 2.93 to 3.11 and 2.83 to 3.01.

Robert

http://www.diodes.com/datasheets/APX803.pdf

Hello Robert,

if you can connect a programmable power supply, you can find the trip point for the BOR on the specific part. That would be useful to see f the external SVC is still below the BOR thresholds.

Regards

Amit