unintentional negative input into ADC

500 microVolts isn't going to damage the MSP430 or cause strange behavior. Indeed, I would question what the accuracy is of that measurement you are making. Unless you are measuring that voltage right at the MSP430 ground and ADC input pins, there is likely some amount of ground plane voltage potential on your board.

The specifications for negative voltage on the MSP430 pins is called out in the datasheet. You would need to have 3 orders of magnitude more negative voltage before you would have to start worrying.

Kelley Maynard said:

I see that it periodically goes slightly negative (-0.0005V)

This is well below 1 LSB of the 10 bit ADC. It is most likely result of some floating point processing.

Peter

I'm working along with Kelley on this project. The code we're using is looking for minimums of the sensor signal. The msp430g2553 can accept an input as low as -0.3 V so we now agree that it doesn't seem like railing of the op-amp signal should be a problem. Unfortunately, there still seems to be a correlation between railing and erratic behavior. When the input into the adc rails at 0 V, the signal minimum sometimes isn’t detected. I’m also running the sensor signal through a matlab simulation that is used to confirm the msp430’s minimum detection algorithm. The minimums that sometimes aren’t detected by the msp430 are always detected by matlab.

This is shown in the picture below. The blue line notes when the msp430 detects a minimum and turns on and off an LED. The black star notes when the matlab simulation detects a minimum. In the picture, the msp430 misses a lot of minimums but not all. (The caption is supposed to read "msp430 misses minimums that matlab detects".

Another example (see below). In this figure, railing occurs at the beginning of the graph. An LED turns on when a minimum is detected and is supposed to turn off 0.1 seconds later but instead stays on for 3.5 seconds, causing 2 minimums to be missed.

Could this be due to the ADC constantly reading 0 when railing’s occurring? Could that cause the code to get stuck somewhere? Maybe in an interrupt?

Thanks!

It’s not clear for me what kind of minimum the MSP shall detect. Looking at example two, there are way more local min or max locations that the drawing marks. Actually, due to noise, there should be plenty of them. SO the question is, how does your MSP code filter noise and detect a ‘real’ minimum (or rather: what defines a minimum)?
Maybe this noise is the problem: if three subsequent samples within your 0.1s interval have a high-low-high pattern due to noise, this may trigger another minimum and prolong the LED-on time.

I don't think that's the problem. The code is constantly looking for a minimum by comparing one sample to the next so you're right that a lot of local minimums are detected. A true minimum is detected once the signal has increased above a threshold.

We are still having issues with the code behaving erratically and I'm now wondering if it could be something to do with the interrupts. We have 3 interrupts (one for the ADC). Could the code temporarily get stuck in an interrupt if more than one fires at the same time?

Multiple simultaneous interrupts are no problem for the MSP, but of course it can be a problem for your code J
If multiple interrupts are pending at the same time (e.g. because GIE was clear), the one with the highest priority (see datasheet) is served first.
While its ISR executes, all other interrupts remain pending and won’t interrupt the ISR. When the ISR exits, the next pending interrupt is served, based on priority.