Hi Group, I have a project where I use timer A as an RTC, the watchdog timer as a general system watchdog and then timer B as a 16 hz sample timer for the internal AD, plus USART0 and 1 in use as well. I have two configurations which seem to lose a second or add a second to my RTC. The WDT, Timer A, USART1 in SPI mode are common, with XT12768 Hz/6pF and XT2=7.3728MHz. Case 1: Common interrupts listed plus 16 Hz on timer B triggering AD capture, then using the AD capture interrupt. We time stamp the data and batch write to an SD card at 80 second intervals (memory related timing). The odd part is that we get a very consistent 1 second skip every 2186 seconds. ie by checking our recorded interval, it goes from 13:12:04 sample 1 to 13:12:06 sample 1 every 2186 seconds. It is very consistent, over several days. That and the RTC appears to be losing time at a much faster rate than expected as in minutes per day. Case 2: Common interrupts listed plus USART0 in UART mode at 115200 Baud. This reads compressed data from an external device to the SD card anywhere from 1 minute to 1 hour intervals. When it does, it is using the UART interrupts for the reading and writing of data, with Timer A for the RTC, and the WDT going as well. It takes 5-10 seconds to transfer the data and seems to lose 1 sec from the internal RTC each time. Any thoughts or comments would be appreciated. Thanks DBW
Interrupt /RTC overlap issue
Started by ●July 18, 2005
Reply by ●July 18, 20052005-07-18
The most obvious thought would be that you are missing a timer interrupt
entirely. This will often show such repetitive behaviour. That at
precisely 2186 iterations there are too many pending interrupts and one
gets dropped. 115200 baud is fairly quick in a well used system. What do
your ISRs look like? My rule of thumb is for the total sum of ISR
execution speeds, ie if all ISRs had to execute sequentially, the total
time would be preferrably half or less of the minimum interval between
any sequential ISR calls. ie if you fastest isr rerquires service every
80 clock cycles you cannot expect to service every one if the total time
required to service the remaining ISRs is 100 clock cycles. This is why
an ISR should be lean and mean, and only recognise events, not process
them. In your case 1 it sounds like you are close, but accumulative time
is just missing one such event on a regular schedule.
I'd start by making XT2 8MHz and making my ISR's as compact as
possible.
No CALLs from ISR;'s, and no more than 8 instructions.
Al
dbwright wrote:
>Hi Group,
>I have a project where I use timer A as an RTC, the watchdog timer as
>a general system watchdog and then timer B as a 16 hz sample timer for
>the internal AD, plus USART0 and 1 in use as well.
>I have two configurations which seem to lose a second or add a second
>to my RTC. The WDT, Timer A, USART1 in SPI mode are common, with
>XT12768 Hz/6pF and XT2=7.3728MHz.
>
>Case 1: Common interrupts listed plus 16 Hz on timer B triggering AD
>capture, then using the AD capture interrupt. We time stamp the data
>and batch write to an SD card at 80 second intervals (memory related
>timing).
>The odd part is that we get a very consistent 1 second skip every 2186
>seconds. ie by checking our recorded interval, it goes from 13:12:04
>sample 1 to 13:12:06 sample 1 every 2186 seconds. It is very
>consistent, over several days. That and the RTC appears to be losing
>time at a much faster rate than expected as in minutes per day.
>Case 2: Common interrupts listed plus USART0 in UART mode at 115200 Baud.
>This reads compressed data from an external device to the SD card
>anywhere from 1 minute to 1 hour intervals. When it does, it is using
>the UART interrupts for the reading and writing of data, with Timer A
>for the RTC, and the WDT going as well. It takes 5-10 seconds to
>transfer the data and seems to lose 1 sec from the internal RTC each
>time.
>Any thoughts or comments would be appreciated.
>Thanks
>DBW
>
>
>
>
>
>
>
>
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
Reply by ●July 18, 20052005-07-18
I was wondering about that. I started with very lean ISR's, but have added a call or two into a couple of them, particularly to compress the AD data on the fly. Think I'll put more emphasis on rewriting things now though. I thought I may be missing an interrupt, but this lost or added second doesn't really overlap a busy time interval. If everything was to run sequentially, it is tight, so that may be it right there. Basically I'll focus on keeping the ISR's very short. For the RTC, I have been using the up counter mode, but from more reading in the TI specs, this adds some interrupt latency, versus using the continuous mode. And I am also beginning to wonder if I crossed up a 12.5pf crystal with a 6 pf crystal, as my clock is losing a second every 4 minutes (about 134 low freq. clock cycles). Time to go back to the protoboard and test it there I guess. Thoughts on the RTC? And thanks for your input otherwise Al. - dbw --- In msp430@msp4..., Onestone <onestone@b...> wrote: > The most obvious thought would be that you are missing a timer interrupt > entirely. This will often show such repetitive behaviour. That at > precisely 2186 iterations there are too many pending interrupts and one > gets dropped. 115200 baud is fairly quick in a well used system. What do > your ISRs look like? My rule of thumb is for the total sum of ISR > execution speeds, ie if all ISRs had to execute sequentially, the total > time would be preferrably half or less of the minimum interval between > any sequential ISR calls. ie if you fastest isr rerquires service every > 80 clock cycles you cannot expect to service every one if the total time > required to service the remaining ISRs is 100 clock cycles. This is why > an ISR should be lean and mean, and only recognise events, not process > them. In your case 1 it sounds like you are close, but accumulative time > is just missing one such event on a regular schedule. > > I'd start by making XT2 8MHz and making my ISR's as compact as possible. > No CALLs from ISR;'s, and no more than 8 instructions. > > Al > > dbwright wrote: > > >Hi Group, > >I have a project where I use timer A as an RTC, the watchdog timer as > >a general system watchdog and then timer B as a 16 hz sample timer for > >the internal AD, plus USART0 and 1 in use as well. > >I have two configurations which seem to lose a second or add a second > >to my RTC. The WDT, Timer A, USART1 in SPI mode are common, with > >XT12768 Hz/6pF and XT2=7.3728MHz. > > > >Case 1: Common interrupts listed plus 16 Hz on timer B triggering AD > >capture, then using the AD capture interrupt. We time stamp the data > >and batch write to an SD card at 80 second intervals (memory related > >timing). > >The odd part is that we get a very consistent 1 second skip every 2186 > >seconds. ie by checking our recorded interval, it goes from 13:12:04 > >sample 1 to 13:12:06 sample 1 every 2186 seconds. It is very > >consistent, over several days. That and the RTC appears to be losing > >time at a much faster rate than expected as in minutes per day. > >Case 2: Common interrupts listed plus USART0 in UART mode at 115200 Baud. > >This reads compressed data from an external device to the SD card > >anywhere from 1 minute to 1 hour intervals. When it does, it is using > >the UART interrupts for the reading and writing of data, with Timer A > >for the RTC, and the WDT going as well. It takes 5-10 seconds to > >transfer the data and seems to lose 1 sec from the internal RTC each > >time. > >Any thoughts or comments would be appreciated. > >Thanks > >DBW > > > > > > > > > > > > > > > > > > > >. > > > > > >Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > >
Reply by ●July 18, 20052005-07-18
dbwright wrote: >I was wondering about that. I started with very lean ISR's, but have >added a call or two into a couple of them, particularly to compress >the AD data on the fly. > Criminal behaviour... :-D > Think I'll put more emphasis on rewriting >things now though. I thought I may be missing an interrupt, but this >lost or added second doesn't really overlap a busy time interval. If >everything was to run sequentially, it is tight, so that may be it >right there. >Basically I'll focus on keeping the ISR's very short. >For the RTC, I have been using the up counter mode, but from more >reading in the TI specs, this adds some interrupt latency, versus >using the continuous mode. > Much better using continuous mode than up counter mode. You can always set your 1 sec ISR to the correct intervals if you like, but 2 seconds reduces the loading slightly. > And I am also beginning to wonder if I >crossed up a 12.5pf crystal with a 6 pf crystal, as my clock is >losing a second every 4 minutes (about 134 low freq. clock cycles). > That sounds like more than just a crystal loading issue, but you can readily confirm this by outputting ACLK on an IO pin and timing it with a scope, or frequency counter. If you are using one of the larger parts like the 149 you can even use the high speed crystal to check on the clock crystal stability >Time to go back to the protoboard and test it there I guess. >Thoughts on the RTC? >And thanks for your input otherwise Al. > You're welcome. Al >- dbw > >--- In msp430@msp4..., Onestone <onestone@b...> wrote: > > >>The most obvious thought would be that you are missing a timer >> >> >interrupt > > >>entirely. This will often show such repetitive behaviour. That at >>precisely 2186 iterations there are too many pending interrupts and one >>gets dropped. 115200 baud is fairly quick in a well used system. >> >> >What do > > >>your ISRs look like? My rule of thumb is for the total sum of ISR >>execution speeds, ie if all ISRs had to execute sequentially, the total >>time would be preferrably half or less of the minimum interval between >>any sequential ISR calls. ie if you fastest isr rerquires service every >>80 clock cycles you cannot expect to service every one if the total >> >> >time > > >>required to service the remaining ISRs is 100 clock cycles. This is why >>an ISR should be lean and mean, and only recognise events, not process >>them. In your case 1 it sounds like you are close, but accumulative >> >> >time > > >>is just missing one such event on a regular schedule. >> >>I'd start by making XT2 8MHz and making my ISR's as compact as >> >> >possible. > > >>No CALLs from ISR;'s, and no more than 8 instructions. >> >>Al >> >>dbwright wrote: >> >> >> >>>Hi Group, >>>I have a project where I use timer A as an RTC, the watchdog timer as >>>a general system watchdog and then timer B as a 16 hz sample timer for >>>the internal AD, plus USART0 and 1 in use as well. >>>I have two configurations which seem to lose a second or add a second >>>to my RTC. The WDT, Timer A, USART1 in SPI mode are common, with >>>XT12768 Hz/6pF and XT2=7.3728MHz. >>> >>>Case 1: Common interrupts listed plus 16 Hz on timer B triggering AD >>>capture, then using the AD capture interrupt. We time stamp the data >>>and batch write to an SD card at 80 second intervals (memory related >>>timing). >>>The odd part is that we get a very consistent 1 second skip every 2186 >>>seconds. ie by checking our recorded interval, it goes from 13:12:04 >>>sample 1 to 13:12:06 sample 1 every 2186 seconds. It is very >>>consistent, over several days. That and the RTC appears to be losing >>>time at a much faster rate than expected as in minutes per day. >>>Case 2: Common interrupts listed plus USART0 in UART mode at 115200 >>> >>> >Baud. > > >>>This reads compressed data from an external device to the SD card >>>anywhere from 1 minute to 1 hour intervals. When it does, it is using >>>the UART interrupts for the reading and writing of data, with Timer A >>>for the RTC, and the WDT going as well. It takes 5-10 seconds to >>>transfer the data and seems to lose 1 sec from the internal RTC each >>>time. >>>Any thoughts or comments would be appreciated. >>>Thanks >>>DBW >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>. >>> >>> >>>Yahoo! Groups Links >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> > > > > >. > > >Yahoo! Groups Links > > > > > > > > > >
Reply by ●July 19, 20052005-07-19
Hello Al, > >I was wondering about that. I started with very lean ISR's, but have > >added a call or two into a couple of them, particularly to compress > >the AD data on the fly. > > > Criminal behaviour... :-D We call that "feature creep" when the marketeers aren't around ;-) > > And I am also beginning to wonder if I > >crossed up a 12.5pf crystal with a 6 pf crystal, as my clock is > >losing a second every 4 minutes (about 134 low freq. clock cycles). > > > That sounds like more than just a crystal loading issue, but you can > readily confirm this by outputting ACLK on an IO pin and timing it with > a scope, or frequency counter. If you are using one of the larger parts > like the 149 you can even use the high speed crystal to check on the > clock crystal stability Agree. One second in 240 seconds is almost 1/2%. That is way more than the usual crystal can be off. I'd stick a scope to it (Xout) and check whether the oscillation looks normal. A trick that I use when no counter is around is to hold an AM radio next to it and listen to the beat between 32768Hz harmonics and a weak station. This needs to be done with at least two stations since you won't know which side of the station's carrier your harmonic is on. Or use a small cap to tap a crystal pin to GND. Since my musical talent is sub par I often fire up a generator with a speaker connected to it to figure out what the beat frequency is. Don't use any low power community radio stations here. It has to be a major station with modern equipment where you can be sure that their carrier frequency is accurate enough. Regards, Joerg http://www.analogconsultants.com/
Reply by ●July 19, 20052005-07-19
Joerg Schulze-Clewing wrote: >Hello Al, > > > >>>I was wondering about that. I started with very lean ISR's, but have >>>added a call or two into a couple of them, particularly to compress >>>the AD data on the fly. >>> >>> >>> >>Criminal behaviour... :-D >> >> > >We call that "feature creep" when the marketeers aren't around ;-) > I used to tell them point blank I figured I was worth more to the company than them. Al > > > >>> And I am also beginning to wonder if I >>>crossed up a 12.5pf crystal with a 6 pf crystal, as my clock is >>>losing a second every 4 minutes (about 134 low freq. clock cycles). >>> >>> >>> >>That sounds like more than just a crystal loading issue, but you can >>readily confirm this by outputting ACLK on an IO pin and timing it with >>a scope, or frequency counter. If you are using one of the larger parts >>like the 149 you can even use the high speed crystal to check on the >>clock crystal stability >> >> > >Agree. One second in 240 seconds is almost 1/2%. That is way more than >the usual crystal can be off. I'd stick a scope to it (Xout) and check >whether the oscillation looks normal. A trick that I use when no >counter is around is to hold an AM radio next to it and listen to the >beat between 32768Hz harmonics and a weak station. This needs to be >done with at least two stations since you won't know which side of the >station's carrier your harmonic is on. Or use a small cap to tap a >crystal pin to GND. Since my musical talent is sub par I often fire up >a generator with a speaker connected to it to figure out what the beat >frequency is. > >Don't use any low power community radio stations here. It has to be a >major station with modern equipment where you can be sure that their >carrier frequency is accurate enough. > >Regards, Joerg > >http://www.analogconsultants.com/ > > > > > > > >. > > >Yahoo! Groups Links > > > > > > > > > >
Reply by ●July 19, 20052005-07-19
Hello Al, > >We call that "feature creep" when the marketeers aren't around ;-) > > > I used to tell them point blank I figured I was worth more to the > company than them. My first contact with Marketing resulted in marriage :-) Regards, Joerg http://www.analogconsultants.com/
