[Tinyos-help] Surprising Timer Readings

[Anton]

Hello.

I perform a simple experiment: a TinyOS 2.0.2 application reads the 
32kHz-timer (using interface Alarm<T32khz, uint32_t> provided by 
Alarm32khz32C.nc) and forwards the reading to computer. This happens 
each time when another timer fires (accessed via interface Timer<TMilli> 
provided by TimerMilliC.nc) - periodically once a second. I did several 
such experiments (several thousand readings in each one).

At first, the values are usual, e.g. 0xF0144, 0xF8144, 0x100144 and so 
on, i.e. the difference between two consecutive values is always 0x8000 
(since each second the content of the 32kHz timer increases by 32768).

But the readings around 250th, 750th, 1250th, 1750th etc. second from 
the beginning of the experiment are strange. For example, 0x7D01A5 is 
followed by this sequence: 0x7D81A5 (it's more by 0x8000 than the 
previous, so it's all right), 0x7D01A5 (it's less by 0x8000 than the 
previous!), 0x7D81A5 (it's OK with regard to the previous) and 0x7F01A5 
(it's more by 0x18000 than the previous!).

It looks like when the timer should go from 0x7DFFFF to 0x7F0000 it goes 
actually from 0x7DFFFF to 0x7D0000 (the first pair of values in the 
aforementioned sequence), i.e. the upper word is not incremented at all. 
But when the timer should go from 0x7DFFFF to 0x7E0000 it goes from 
0x7DFFFF directly to 0x7F0000 (the last pair in the sequence), i.e the 
upper word is incremented by 2 right away.

So, this "error and compensation" happens approximately every 500 
seconds starting from 250th second of the experiment. I think this is 
somehow related to the handling of the 16-bit 32kHz timer overflow. But 
it's not clear why exactly when the timer content should change from 
0x7DFFFF to 0x7F0000, from 0x17D0000 to 0x17E0000 etc.

Could anybody explain it?

Anton.