For loop exiting before completing all tasks - how to diagnose?

Does not KISS suggest that you simply test/verify your ADC code "free" from the (other) confounding influences?

Your use of an ADC time delay - to make a display more readable - cannot result from your deep thought & planning.   (from your time here - we know you're far smarter than to "walk that sub-optimal" path...)  (i.e. don't poison the ADC's well - "freeze" the display for viewing by less brutal means!)

Yes, that's a good point... however I haven't yet verified if removing the ADC processing fixes the problem. I'm concerned because I always see the problem when the ADC is running, but of course it's harder to prove that it never happens when the ADC isn't running.

As to the time delay in ADC code... I hadn't thought about it much, but I agree this is sub-optimal. Sadly, the code is from TIs example for single-ended ADC:

    while(1)
    {
        //
        // Trigger the ADC conversion.
        //
        ADCProcessorTrigger(ADC0_BASE, 3);

        //
        // Wait for conversion to be completed.
        //
        while(!ADCIntStatus(ADC0_BASE, 3, false))
        {
        }

        //
        // Clear the ADC interrupt flag.
        //
        ADCIntClear(ADC0_BASE, 3);

        //
        // Read ADC Value.
        //
        ADCSequenceDataGet(ADC0_BASE, 3, pui32ADC0Value);

        //
        // Display the AIN0 (PE7) digital value on the console.
        //
        UARTprintf("AIN0 = %4d\r", pui32ADC0Value[0]);

        //
        // This function provides a means of generating a constant length
        // delay.  The function delay (in cycles) = 3 * parameter.  Delay
        // 250ms arbitrarily.
        //
        SysCtlDelay(SysCtlClockGet() / 12);
    }

I assume using a timer interrupt would be a preferable way to implement this? Or perhaps some sort of filter to only update the display for larger swings in value?

That would be one way to start Lee, but don't approach it as a patch job.

Better to redesign your approach I think.

You currently have multiple relatively independent processes. I see

• Serial I/O
• Communication Protocol
• Command Parsing
• Relay driving
• A/D running
• Display

Some of these could be combined or re-arranged.  Especially since I don't know your application.

However, just to focus a bit. From what you've showed it appears that the A/D and display are independent of the rest. Quite likely that will change but for now it's a place to start.

There is no reason the A/D and display update need to be synchronous with the communications and relay. So let's run them separately (I'll get to how later). Also given that your display is much slower than what the A/D capable of you do not necessarily need to run them at the same speed or indeed synchronously. If you filter the A/D results you actually improve the stability of the results (not necessarily the accuracy). If the A/D is enough faster than the display you may be able to run them independently since the difference between successive results is too small to matter.

So alternative 1 for A/D and display

A/D runs in it's own process along with filtering.  This filter puts it's results into a global location/mailbox to be read by other processes

The display runs in an independent process and periodically reads the filtered values and displays them.

Alternative 2 for A/D and display

Slightly more complex, the A/D process is synchronized with the display process.

The A/D runs in it's own process along with any filtering. The filter may make it's results available as previously but every n'th conversion it triggers the display process. Maybe passing the updated results through a queue.

So how to run this as separate processes?

You could use an RTOS. I'd suggest doing that at some point.

There is a simpler way to start with. It's usually called a super-loop

In pseudo code something like

while(TRUE) {

     run_ad()

     run_display()

    ....

     }

run_ad becomes something like

if time() > last_ad_time + ad_period {

      do_conversion()

      filter_conversions()

      last_ad_time = time()

     }

and run_display becomes something like

if time > last_display_time + display_period {

    update_display()

    }

There are multiple approaches that range from this simple method to a full RTOS, each applicable to its own area of use.

Robert