We use Rabbit RCM3750
mstimer is 8 bytes and wraps around every 49 days
These are specific dates/times, e,g,:
2013-10-15 2013-08-27 2013-07-08 2013-05-19 2013-03-26 2013-02-04 2012-12-16
which gives a problem in our app.
(I have solved the problem in software)
However I 'm not able to reproduce the problem (with old software) so I can’t test my solution.
It seems that in new firmware mstimer is cleared on hardware/software reset. (at least with the debugger/programmer)
From which firmware is:
- mstimer reset on hardware/software reset
- mstimer calculated on the hardwareclock
Dynamic C 10 users manual:
7.3.2 Example: Delay Loop
An important detail about MS_TIMER is that it overflows (“rolls over”) approximately every 49 days, 17
hours. This behavior causes the following delay loop code to fail:
/* THIS CODE WILL FAIL!! */
endtime = MS_TIMER + delay;
while (MS_TIMER < endtime) {
//do something
}
If “MS_TIMER + delay” overflows, this returns immediately. The correct way to code the delay loop so
that an overflow of MS_TIMER does not break it, is this:
endtime = MS_TIMER + delay;
while ((long)MS_TIMER - endtime < 0) {
//do something
}
The interval defined by the subtraction is always correct. This is true because the value of the interval is
based on the values of MS_TIMER and “endtime” relative to one another, so the actual value of these variable
does not matter.
One way to conceptualize why the second code snippet is always correct is to consider a number circle like
the one in Figure 7.1. In this example, delay=5. Notice that the value chosen for MS_TIMER will “roll
over” but that it is only when MS_TIMER equals or is greater than “endtime” that the while loop will evaluate
to false.
Another important point to consider is that the interval is cast to a signed number, which means that any
number with the high bit set is negative. This is necessary in order for the interval to be less than zero
when MS_TIMER is a large number.
Thanks for your answer. That’s also the way I did fix the program.
The problem is that I cannot simulate the problem with the old program, and thus also cannot test the fix.
I suspect that old firmware calculates mstimer on RTC
(because the problem was on specific dates in different installations)
but new firmware reset mstimer on reboot.
So the question is
How is mstimer calculated on reboot ?
Was is different with older firmware?
OK I found it: mstimer is cleared at reset. (not calculated on clock)
I have in different installations the exact the same date because there is a build in Summer/Winter Daylight saving
which reset the rabbat on last Zonday of March and October.
Meaning the rabbit runs quite stable, runs without reset for at least half a year and resets only on request.