ADC lockup problems

Started by lancenz1 December 10, 2003
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



Beginning Microcontrollers with the MSP430

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/ 
> 
> 
> 


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/ 
> > 
> > 
> >


--- 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



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
> 
> 
> 


__________________________________


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


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
> 
> 


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/ 
> 
> 
> 


--- 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