[Tinyos-help] [tinyos2.0] event timer.fired() getting lost on telosb using BlinkToRadio apps.

[Cory Sharp]

I've committed fixes to VirtualizeTimerC and VirtualizeAlarmC to
tinyos-2_0_devel-BRANCH.

Both components would fail if an alarm/timer was overdue.  An overdue
Timer in VirtualizeTimerC would only affect that particular virtual
timer.  An overdue Alarm in VirtualizeAlarmC would affect all
virtualized alarms in that component.  I have tested my updates to
both components and believe the issues are resolved.

Here's my commit log:

* Fixed a bug in VirtualizeTimerC that caused "late timers" to catastrophically
fail and not fire again for a very long time.  This required a small fix.

* Fixed a related bug in VirtualizeAlarmC that caused "late alarms" to
catastrophically impact the behavior of other virtual alarms.  The complete bug
was fairly subtle and required a minor overhaul of the component.

Cory

On 7/25/06, ipark at ncsu.edu <ipark at ncsu.edu> wrote:
> Hi,
>
> I've executed BlinkToRadio application with two telosb motes for about 3
> hours after adding one line of code in VirtualizeTimerC.nc.
> These two motes are still operating correctly without event timer.fired()
> getting lost.
> It seems that the bug's been fixed.
> Thank you.
>
> Inyong Park
>
> > Whoah, it looks like I have a blatantly ugly bug in VirtualizeTimerC
> > in lib/timer/ where the remaining time is not correctly calculated for
> > an overdue periodic timer.
> >
> > Note, the radio does not play a significant role.  If you take
> > Jonathan's sample application, take out all the radio stuff, and
> > busywait for 1ms in the fast timer, the problem still occurs.  I'm
> > surprised that other platforms report to not have this problem,
> > because they should.
> >
> > As a quick hack to see if it solves the problem on your side of
> > things, try adding this one line of code at around line 100 in
> > VirtualizeTimerC.nc:
> >
> >           else
> >           {
> >             // The remaining time is non-positive (the timer had fired).
> >             // So add dt to convert it to remaining for the next event.
> >             timer->t0 += timer->dt;
> >             remaining += timer->dt;
> >             if (remaining & 0x80000000L) remaining = 0;  // <-- ADD THIS
> > LINE
> >           }
> >
> > If a couple of you can test that, then I'll try to mix up a cleaner
> > solution and review the rest of the VirtualizeTimerC code.
> >
> > Thanks,
> > Cory
> >
> > On 7/24/06, Cory Sharp <cory at moteiv.com> wrote:
> >> Boomerang has no significant changes from the 2.x timer stack.  We are
> >> actively looking into this issue, now. - Cory
> >>
> >> On 7/23/06, Philip Levis <pal at cs.stanford.edu> wrote:
> >> > On Jul 23, 2006, at 11:37 AM, Jonathan Hui wrote:
> >> >
> >> > > After a little testing, it looks like the radio stack is still
> >> alive.
> >> > > I modified BlinkToRadio to maintain two timers (1ms and 1s period),
> >> > > both of which attemps to send a message on each fire event. After a
> >> > > few moments, the 1ms timer will fail to fire, but the 1s timer will
> >> > > continue firing and sending messages. Even more interesting is that
> >> > > the 1ms timer starts firing at the same period as the 1s timer.
> >> > >
> >> > > It's probably the case that the radio stack is somehow affecting the
> >> > > operation of the msp430 timer stack and causing it to fail in
> >> > > repeatedly firing the 1ms timer. Haven't dug too much into the timer
> >> > > code to understand why this is.
> >> > >
> >> > > I've attached the modified app I used to test.
> >> > >
> >> > > Cory, do you have an ideas?
> >> >
> >> > Yeah, I should have given more background. I think it's definitely
> >> > the case that it's the MSP430 timer stack, which runs into some
> >> > issues when timers are at too fast a rate (e.g., 1ms). E.g., in the
> >> > 2.0 tutorials, there's a part where you try using very long tasks of
> >> > different length to show the run-to-completion semantics. On atm128
> >> > platforms, a task that's too long causes you to lose timer events but
> >> > things continue as expected; on msp430 ones, the timer stack can act
> >> > erratically.
> >> >
> >> > Joe, Cory, does Boomerang 2.0.2 use the 2.x timer stack unchanged, or
> >> > have you incorporated fixes?
> >> >
> >> > Phil
> >> >
> >>
> > _______________________________________________
> > Tinyos-help mailing list
> > Tinyos-help at Millennium.Berkeley.EDU
> > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
> >
>