[Tinyos Core WG] msp430 timer issues

[Vlado Handziski]

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.


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