Hi everyone. I have a bit of a strange problem with an MSP430F149. The ADC runs for a while and then locks up , about once an hour or so yet all other processes carry on just fine. I have confirmed the ADC is not updating ADC12MEMx locations. A power on/off cycle usually wont fix it but a reprogram will. The supply voltage is stable at 3.1 volts. I suspect the ADC internal oscillator is stopping but I am not sure how to confirm this. Any tips, prior experiences etc would be appreciated. Lance ICM
ADC lockup problems
Started by ●December 10, 2003
Reply by ●December 11, 20032003-12-11
All other things being equal, have you tried a) using a crystal as the
ADC clock source, or b) when the event occurs have you checked all ADC
registers. Do you refresh you critical registers frequently, or do you
just assume that, because they were set at power on that they remain the
same? registers can be corrupted by many external influences.
Al
lancenz1 wrote:
> Hi everyone.
> I have a bit of a strange problem with an MSP430F149.
> The ADC runs for a while and then locks up , about once an hour or
> so yet all other processes carry on just fine. I have confirmed the
> ADC is not updating ADC12MEMx locations.
> A power on/off cycle usually wont fix it but a reprogram will. The
> supply voltage is stable at 3.1 volts.
>
> I suspect the ADC internal oscillator is stopping but I am not sure
> how to confirm this.
>
> Any tips, prior experiences etc would be appreciated.
>
> Lance
> ICM
>
>
>
>
> .
>
>
>
> ">http://docs.yahoo.com/info/terms/
>
>
>
Reply by ●December 11, 20032003-12-11
Thanks Al Periodicaly reloading the ADC registers stopped it locking up. I have never had to do that with a micro before. I will attempt to discover why later on, the fact that is fixed for now will do (ever present time pressure). The nearest I had to this was a PIC that took 1 second to comlete an ADC conversion if the IC got too hot. Thanks again Lance --- In msp430@msp4..., onestone <onestone@b...> wrote: > All other things being equal, have you tried a) using a crystal as the > ADC clock source, or b) when the event occurs have you checked all ADC > registers. Do you refresh you critical registers frequently, or do you > just assume that, because they were set at power on that they remain the > same? registers can be corrupted by many external influences. > > Al > > lancenz1 wrote: > > > Hi everyone. > > I have a bit of a strange problem with an MSP430F149. > > The ADC runs for a while and then locks up , about once an hour or > > so yet all other processes carry on just fine. I have confirmed the > > ADC is not updating ADC12MEMx locations. > > A power on/off cycle usually wont fix it but a reprogram will. The > > supply voltage is stable at 3.1 volts. > > > > I suspect the ADC internal oscillator is stopping but I am not sure > > how to confirm this. > > > > Any tips, prior experiences etc would be appreciated. > > > > Lance > > ICM > > > > > > > > > > . > > > > > > > > ">http://docs.yahoo.com/info/terms/ > > > > > >
Reply by ●December 12, 20032003-12-12
--- In msp430@msp4..., onestone <onestone@b...> wrote: > Do you refresh you critical registers frequently, or do you > just assume that, because they were set at power on that they remain the > same? registers can be corrupted by many external influences. I hope you don't really mean that! The statistical likelihood that some bit in some random register just flips unexpecedly had sure as heck better be almost nil when operated at normal temperature, at sea level (not at high altitudes), etc. If someone told me some register was randomly flipping a bit on somewhat regular intervals, I'd be willing to bet them a fairly hefty sum that they simply had a bug in their program that was trashing it from time to time. FAR more likely than the 'random gamma ray flipped my bit' approach. I'd also suggest that regularly 'refreshing' critical registers on a microcontroller is a good way to hide bugs from yourself. :-( ---Joel Kolstad
Reply by ●December 12, 20032003-12-12
Hi Al
I am also suprised. I understand that low voltage
devices suffer from lower noise immunity. But isnt
this a poor design : that one has to periodically
refresh contents of register /variables to make sure
that the software behaves as expected.
All this beign said assuming that a clean supply was
porvided to the MCU
Do other MCUs from Motorola and Hitachi suffer from
the same.
Its hard to digest this.
Please advise
thanks
Harshit
--- Joel Kolstad <kolstajo@kols...> wrote:
> --- In msp430@msp4..., onestone
> <onestone@b...> wrote:
> > Do you refresh you critical registers frequently,
> or do you
> > just assume that, because they were set at power
> on that they
> remain the
> > same? registers can be corrupted by many external
> influences.
>
> I hope you don't really mean that! The statistical
> likelihood that
> some bit in some random register just flips
> unexpecedly had sure as
> heck better be almost nil when operated at normal
> temperature, at
> sea level (not at high altitudes), etc.
>
> If someone told me some register was randomly
> flipping a bit on
> somewhat regular intervals, I'd be willing to bet
> them a fairly
> hefty sum that they simply had a bug in their
> program that was
> trashing it from time to time. FAR more likely than
> the 'random
> gamma ray flipped my bit' approach.
>
> I'd also suggest that regularly 'refreshing'
> critical registers on a
> microcontroller is a good way to hide bugs from
> yourself. :-(
>
> ---Joel Kolstad
>
>
>
__________________________________
Reply by ●December 14, 20032003-12-14
Hi all that replied. It is worth saying that this is a high transient environment application. I am pretty sure I have gone to reasonable lenghts to keep the micro locked down but I have to suspect some transient might be geting at it although I have tried long and hard to capture any such thing. I have split ground plains, decoupling etc and I am familiar with applications in this sort of environment. It was the long time between failures that was throwing me and why I contacted the group for similar experiences. Reloading the registers does fix it but I am very aware this is a band aid and not a root cause and is a butt biting event waiting to happen. What this does tell me is that it is a corrupting register and is most likly a hardware issue due to the long interval as I have no long timed software events and such. Now that I have ruled out the ADC oscillator, I am looking long and hard at the reset pin for ripples, flicks and the ground inputs and any variance between the digital and analog as they have different routes back to unified ground. Lance
Reply by ●December 15, 20032003-12-15
Without looking at the circuit its hard to guess what
the problem might be.
Try decreasing the pull up/down resistor values and
check if the frequency of problem goes down.
-Sumukh
--- lancenz1 <lance@lanc...> wrote:
> Hi all that replied.
> It is worth saying that this is a high transient
> environment
> application. I am pretty sure I have gone to
> reasonable lenghts to
> keep the micro locked down but I have to suspect
> some transient
> might be geting at it although I have tried long and
> hard to capture
> any such thing. I have split ground plains,
> decoupling etc and I am
> familiar with applications in this sort of
> environment. It was the
> long time between failures that was throwing me and
> why I contacted
> the group for similar experiences.
> Reloading the registers does fix it but I am very
> aware this is a
> band aid and not a root cause and is a butt biting
> event waiting to
> happen.
> What this does tell me is that it is a corrupting
> register and is
> most likly a hardware issue due to the long interval
> as I have no
> long timed software events and such.
> Now that I have ruled out the ADC oscillator, I am
> looking long and
> hard at the reset pin for ripples, flicks and the
> ground inputs and
> any variance between the digital and analog as they
> have different
> routes back to unified ground.
>
>
> Lance
>
>
Reply by ●December 15, 20032003-12-15
Hi Lance, sounds automotive? Ah the joys of load dumps! If Adding a
refresh caused the problem then it should be easily tracable. When I
refresh registers I only refresh those registers which may affect the
operation of the system, and which are not handled by the program. For
example if I set Port1 to outputs and then never need to deal with Port
1 again I'd have:-
INIT:
...
...
mov.b #-1,&P1DIR
...
RET
REFRESH:
MOV.B #-1,&P1DIR
...
RET
However, if at some point in my program I needed to access Port 1 as a
bit, then refresh becomes unnecessary since BIS.B #bit,&P1DIR is a
read-modify-write sequence and automatically refreshes the register.
Your fault should be easy to trace, simply by storing an image of the
refreshed registers with a CRC, Now, instead of refreshing periodically
calculate the CRC, and, when a mismatch is found look for the cause. My
bet? it's something like a missing & or # infront of an
address/variable
or constant name, resulting in a different addressing mode. A single
typo like this is logical, legal, and an absolute bugger to spot if it
doesn't do something catastrophic. It is likely that the side effect
isn't even becoming obvious at the point where the damage occurs. I'd
try a register CRC check as the first step. Find which register then:-
Search the LST file for a match to the address of the register. See if
you can find it as the target in a typo.
next find occurences of the register name and use its address as an
offset for PC then check these code snippets for typos.
My apologies if you already know how to:-
a) suck eggs or
b) walk and chew gum.
Cheers
Al
lancenz1 wrote:
> Hi all that replied.
> It is worth saying that this is a high transient environment
> application. I am pretty sure I have gone to reasonable lenghts to
> keep the micro locked down but I have to suspect some transient
> might be geting at it although I have tried long and hard to capture
> any such thing. I have split ground plains, decoupling etc and I am
> familiar with applications in this sort of environment. It was the
> long time between failures that was throwing me and why I contacted
> the group for similar experiences.
> Reloading the registers does fix it but I am very aware this is a
> band aid and not a root cause and is a butt biting event waiting to
> happen.
> What this does tell me is that it is a corrupting register and is
> most likly a hardware issue due to the long interval as I have no
> long timed software events and such.
> Now that I have ruled out the ADC oscillator, I am looking long and
> hard at the reset pin for ripples, flicks and the ground inputs and
> any variance between the digital and analog as they have different
> routes back to unified ground.
>
>
> Lance
>
>
>
> .
>
>
>
> ">http://docs.yahoo.com/info/terms/
>
>
>
Reply by ●December 15, 20032003-12-15
--- In msp430@msp4..., onestone <onestone@b...> wrote: > Hi Lance, sounds automotive? No, a display technique that looks bright even though its running off the smell of and oily electron. A bit hush hush for now. Very low average power, high energy pulses. The main attraction of the MSP430 is it's very low operating current, nothing beats it. There are some that hybernate better etc but that is not of interest to me. > My apologies if you already know how to:- > > a) suck eggs or > b) walk and chew gum. > > Cheers > > Al > I was trying to head off any tangents at the pass, I realised I was a bit vague with the back ground info so I thought I would clarify things a bit. I welcome any and all comments as one can sometimes miss the blinding obvious. Lance