# Testing Long Time Delay

I have implemented a long time delay using a small microcontroller (MSP430) however I need to test and verify that it does as I expect.

My algorithm is as follows:

main()
{
//Init Timer
//Init Output
//Sleep
}

ISR_Timer()
{
//increment minutes
//if output off and enough time elapsed
//Turn output on
//Reset elapsed time
//else if output on and enough time elapsed
//Turn output off
//Reset elapsed time

}


Due to the delays being 21 hours and 3 hours, how can I go about testing this as it doesn't happen instantly. I have swapped the hours to minutes, although I will need a way to test that the output is off for 21 hours and on for 3 hours, and that nothing happens inside of the microcontroller, such as the watchdog timer reseting the CPU. The code is simple enough that going through it it can be seen that nothing is actually wrong with the implementation but it still needs to be tested in some way.

• This is a very simple timer. Assuming you want more than just changing the time, you should really test the full time. I suggest just making more of your tiny device and parallelizing the process. – mcmiln Nov 25 '15 at 7:35

Power a mechanical clock with the output of the timer. Either a mains clock, or one of these one AA battery cheap clock movements that turn up everywhere, depending on what your test system switches.

Set the test clock to 12:00, record the time you set the timer going. You only need to make three more visits to the test setup, and their times are fairly flexible. Make the first visit before 21 hours, to check the test clock still shows 12:00. Visit between 21 and 24 hours after starting, to check that the test clock is running, and that the time shown indicates that it started when expected. Make the next visit some time between 24 and 45 hours, to make sure that it is stopped, showing a time of 03:00.

If you want documentary evidence of the test working, photograph the test clock next to a normally running time and date clock, and annotate the print by hand to explain what can be concluded from the times.

If you put the test away in a cupboard for a week, then when you come back, the test clock should have advanced 3 hours per day of the test.

• Thats a really neat idea! I'll have to get myself a clock to do it with. – Dean Jan 4 '16 at 13:05

If you have a logging multimeter you can hook that up and actually run the thing for 24 hours. A ghetto-solution is to point a camera to a normal multimeter and let it record for 24 hours. Battery drain on the multimeter is a problem, so you might have to rig up a solution to this unless you have a bench multimeter.

But I don't think you should worry about the watchdog. There are no microcontroller watchdogs longer than a few seconds, and since you're not resetting the watchdog in the ISR, it will still kick in during a shorter test.

Two obvious things that can go wrong comes to mind, and you can test each of them separately: The first is that you mess up the hardware timer settings so the ISR is triggered faster or slower than expected. You can test this by making the time required to flip the outputs shorter within the ISR without touching the hardware code. The second is that you can have issues with overflows in the time keeping counters. This can be tested by keeping the ISR as it is, but making the hardware timer trigger a lot faster.

These tests are easier with a digital oscilloscope with a very long time base.

As an alternative to hand-coding a timing scheme, you could interface to a real-time clock-calendar chip. Many such IC's include an alarm feature which can wake up the microcontroller. Nice thing about the RTCC is, it runs constantly, usually on very little power, and is programmed with a date and time to "alarm" on. Once tested with a shorter time span, longer time spans are almost certainly error-free.