[Tinyos Core WG] msp430 timer issues

[Vlado Handziski]

On 9/4/07, Philip Levis <pal at cs.stanford.edu> wrote:
>
> On Aug 29, 2007, at 7:08 AM, Vlado Handziski wrote:
>
> > I think we all vote for skipping today's conference call :) So here
> > is a short overview of the msp430 issues I proposed for discussion
> > last week. Comments and volunteers are welcomed :)
> >
> >
> > 1. Initialization of the clock system and timers
> >
> > Problem:
> > Currently, Msp430ClockP.nc after initializing the basic clock
> > settings, and performing the initial DCO calibration also
> > configures the two timers and starts them regardless from the fact
> > if the application needs any timer services or not. This not only
> > results in unnecessary interrupts, but also after the un-wiring of
> > the periodic DCO calibration by Cory has lead to significant
> > increase of the Null application consumption ( 1.2mA on telosA). To
> > counter, back then I did a quick and dirty fix by adding
> > Msp430TimerC in Msp430ClockC.nc bringing the consumption back to
> > 4.6uA, without examining the real causes. After David introduced
> > the appdoc option, I was playing with Null and after seeing all the
> > Msp430Timer32khz cram in there I remembered that this needs to be
> > taken care of properly.  The problem seems to occur when TBIE is
> > enabled and Msp430ClockC is not wired in, most likely some default
> > event handler is missing, but why the default reti inserted by libc
> > is not enough, I don't know.
> >
> > Solution:
> > I believe that we should not configure and start the timers by
> > default. Msp430ClockP should init the clock system, perform initial
> > calibration of the DCO and just signal an event that the basic
> > clock setup is done.
> > The configuration and enabling of the timers should happen only if
> > the app actually needs a timer. In the timer code (see below) we
> > should wait on signal from the Msp430ClockP
> > that the clock init is done and perform the clock setup then,
> > knowing now that a proper handler will be also included.
> >
> > 2. Periodic DCO calibration
> >
> > Problem:
> > In the old code that Cory disabled, on each TimerA overflow the
> > TimerB counter was latched, and then the number of TimerB ticks
> > between two TimerA overflows (32 times a second) was compared with
> > a target value in order to periodically recalibrate the DCO
> > frequency. Because this strategy does not work when the MCU goes to
> > sleep Cory has disabled it. So at the moment we are not performing
> > periodic DCO calibration on the msp430 platforms.
> >
> > Solution:
> > The only way to handle this is to explicitly announce to the
> > MCUSleep that the TimerA is used by allocating a dedicated TimerA
> > (see below) for some period so that it can be used for counting
> > TimerB ticks. We can either make the period and duration of this
> > fixed, i.e. do this on each TimerB overflow (each 2 seconds) for
> > some fixed period  (we should check what is the lowest number of
> > timerB ticks that can be used to reliably recalibrate, I guess that
> > we definitely don't need 1/32s as in the old code). Even better
> > these parameters should be exported to the application via HAL/HIL
> > interfaces.
> >
> >
> > 1. Arbitration of TimerA
> >
> > Problem:
> > Currently, several components in the msp430 stack rely on dedicated
> > access to the TimerA resources. For example, both the ADC, the
> > DMA,  and the periodic DCO calibration need such an exclusive
> > access. The ADC needs to set-up the clock in up-down mode, the
> > calibration might need to use it in continues mode with different
> > divider, etc. However, these accesses are currently not guarded
> > with proper arbitration, relying on a "gentlemen's agreement" that
> > is not documented anywhere.
> >
> > Solution:
> > -The current TimerA abstraction needs to be wrapped with a proper
> > arbiter, because of the low overhead of turning the system on and
> > off, we don't need dedicated power manager, we just need to make
> > sure that after release, the timer is put in a state that enables
> > McuSleep  to put the MCU in the appropriate LPM.
> > -The current ADC, DMA code needs to be updated to properly request
> > and release the timer
> >
> > 2. Arbitration of TimerB
> >
> > Problem:
> > In a similar way, the current "gentleman's agreement" is that the
> > TimerB is always running driven from the 32kHz  ACLK, in continuous
> > mode. There are currently no existing components that violate this
> > agreement.
> >
> > Solution:
> > We should consider wrapping TimerB with a NoArbiterC by default.
> > The overhead for this should be quite low, and will make it much
> > easier to "upgrade" to full arbitration if need comes.
> >
>
> These solutions all seem reasonable to me -- I believe (and could be
> mistaken) they are essentially what Boomerang does to deal with these
> issues. My one concern is keeping the stack simple when possible.
>
>
Well, not exactly. In Boomerang, TimerA is arbitrated, TimerB is not. And
although TimerA is not started by default, TimerB is started, and they still
rely on applications including the MSP430TimerC component to properly handle
the TimerB overflow interrupt. The DCO calibration is done on TimerB
overflows, i.e. each 2s.

I think that we should split the Init of the clocks with the setup of the
timers completely, ideally starting the timers only if there is a user level
Alarm/Timer component or a system level PeriodicDCOCalibrate-like component.
As for the calibration, sacrificing one of the TimerB Alarms for more
flexible selection of the period between two calibrations and exporting this
time (as well as the TimerA "on" time during the calibration) to the
application seems like an acceptable trade off to me. I don't think these
changes will complicate the stack much further than it already is :))

Vlado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20070904/0f5089ba/attachment.htm