interupts interfering with serial?

[Frankthetech]

I have a question, a project I'm working on is missing serial1 data at random times.
I'm coding for a teensy 3.2 and trying to use the watchdog timer to prevent the software
from locking up.
But when I disable the watchdog it seems to work fine. So, is it possible that when the watchdog halts interrupts
when I "kick the dog" that the serial1 data could be missed?

 

[rcarr]

Can disabling interrupts for two instruction cycles cause your serial data to fail - my answer would be no unless your program is right on the edge of being out of time resources.

Not much information given. Your could test things by not using the watchdog, but disabling interrupts for a few lines of code elsewhere and see if that causes problems. You could reduce your processor speed and see if you have run out of processing power.

My general opinion of a watchdog is that it causes more problems than it fixes and I suspect your implementation of the watchdog is somehow faulty.

 

[Frankthetech]

I do agree, it's unlikely that a few cycles could cause serial data to be missed.
You are right, I may not use the watchdog. It was more of a learning exercise anyway.
And the reason for this post was to try to understand why..
I set up the watchdog first thing as follows:

#ifdef __cplusplus
extern "C" {
#endif
void startup_early_hook() {
WDOG_TOVALL = 4000; // The next 2 lines sets the time-out value.
WDOG_TOVALH = 0; //about 4 seconds.
WDOG_PRESC = 0; // prescaler
WDOG_STCTRLH = (WDOG_STCTRLH_ALLOWUPDATE | WDOG_STCTRLH_WDOGEN); // Enable WDG
}
#ifdef __cplusplus
}
#endif

and then kick him with;
WatchdogReset();


void WatchdogReset()
{
// kick the dog refresh the watchdog timer
noInterrupts();
WDOG_REFRESH = 0xA602;
WDOG_REFRESH = 0xB480;
interrupts();
delay(1); //delay needed between each refresh is 1ms.
}

I will follow up with more testing as you advised.

 

[KurtE]

My gut tells me that it is unlikely your kick the dog code should impact Serial1 as Serial1 has an 8 entry hardware fifo queue for input and output, which should give the hardware a reasonable amount of time to be able to remove the items from the hardware queue and put it onto the software queue. Now if you were talking about Serial3, then you have less time to respond as it only has a 1 item fifo.

But as mentioned, if your code either has lots of higher priority ISR code that is keeping the Usart0 ISR from running, or you are receiving data faster than you are processing it and the software queue overruns...

 

[rcarr]

>>>delay(1); //delay needed between each refresh is 1ms.

There is a time waster that could cause problems. Are you familiar with the elapsedMillis timers? You could declare one called timer for example and then in loop have some code:

     if( timer > 1000 ){      // reset the watchdog once a second
         WatchdogReset();
         timer = 0;
    }

You remove your delay(1) of course with this approach.