FreeCalypso > hg > freecalypso-tools

comparison doc/Deep-sleep-support @ 427:19cabe7c8e08

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/Deep-sleep-support article written
author Mychaela Falconia <falcon@freecalypso.org>
date Sun, 28 Oct 2018 23:20:00 +0000
parents
children
comparison
equal deleted inserted replaced
426:13f0fc38cefd 427:19cabe7c8e08
1 All standard phones and modems based on the Calypso chipset from TI implement
2 several different power saving modes, called sleep modes, and one of these sleep
3 modes has a profound impact on the operation of the externally visible UART
4 interfaces provided by the device. The power saving mode in question is called
5 deep sleep, and the phone or modem can only enter this deep sleep mode when it
6 is in the so-called idle state, meaning that it is camped on a cell and is ready
7 to receive incoming calls, messages or GPRS packets - deep sleep cannot be
8 entered while in an active call or in the middle of packet data transfer. When
9 a Calypso GSM device is idle with deep sleep enabled, it will only wake up at
10 preprogrammed intervals to listen on the paging channel, and will stay in deep
11 sleep in between these paging windows. Calypso GSM devices also enter deep
12 sleep when they are completely idle with no radio network connection.
13
14 When a Calypso GSM device enters deep sleep, the main VCXO or VCTCXO that runs
15 at 13 or 26 MHz and provides all other clocks in normal operation is completely
16 stopped (powered off), and the only clock that remains running is the 32.768 kHz
17 watch crystal oscillator. The preprogrammed wakeup timing (waking up to listen
18 on the paging channel at the right time) is driven by this 32.768 kHz clock, but
19 the Calypso can also be woken up ahead of the programmed time by an external
20 interrupt such as a button press on the phone keypad.
21
22 This deep sleep mode provides a very important power saving measure (the
23 extremely low current draw that is achieved during deep sleep is not possible
24 without stopping the fast clock), but it presents a real challenge for the
25 external UART interfaces. Consider what happens when an external host sends
26 some characters to one of Calypso's UARTs (either the AT command interface or
27 RVTMUX) while the GSM device is in deep sleep. In normal operation a UART
28 requires a clock of 16x the baud rate (some vendors' UARTs can make do with
29 only 8x the baud rate) in order to receive asynchronous incoming characters,
30 and in the Calypso these UART clocks come from the 13 MHz master clock - but
31 that master clock is stopped during deep sleep!
32
33 Calypso UARTs have some special asynchronous (non-clock-dependent) logic that
34 causes a wakeup signal to be generated if some incoming traffic is detected at
35 a UART while in deep sleep, but the first character that triggers this wakeup
36 will be lost: the asynchronous logic can detect that there is "something
37 happening" on the UART RxD line, but it cannot catch the actual byte content
38 without a clock: the *only* clock available during deep sleep is 32.768 kHz,
39 and even at 9600 baud one would need a clock several times faster than this
40 rate in order to receive and register an incoming byte. Furthermore, wakeup
41 from deep sleep takes a non-trivial length of time, thus if someone tries to
42 send lots of data to a Calypso UART while in deep sleep, quite a bit more than
43 just the first character will be lost: I did some experiments to characterize
44 the delay which needs to be inserted between the first "sacrificial" wakeup
45 character and the subsequent character which is expected to be received
46 correctly, and 40 ms wasn't enough, whereas 60 ms did the trick.
47
48 So how can one have reliable communication with a Calypso GSM device over a
49 UART if the GSM device goes into and out of deep sleep at times which are
50 unpredictable to the external host and if sending characters to the Calypso
51 during deep sleep causes those characters to be lost? The solution involves a
52 special protocol:
53
54 1) On the Calypso side, TI's reference firmware implements a UART activity
55 timer: every time some characters are received at a UART, the timer is reset to
56 10 s, and until that timer expires, the GSM device is not allowed to go into
57 deep sleep.
58
59 2) Host systems sending command traffic to Calypso modems need to keep track of
60 how much time has elapsed since the last time they sent something to the modem,
61 and if enough time has elapsed that the modem is now allowed to enter deep
62 sleep, the host needs to perform a precautionary wakeup transmission before the
63 actual desired one.
64
65 What is a precautionary wakeup transmission? The idea is to send something to
66 the modem can be either accepted or lost by the latter: if the modem happens to
67 be awake at the time, the transmission will be received normally, and if the
68 modem is in deep sleep, the transmission will be lost but will cause the modem
69 to wake up and start the 10 s UART activity timer. Our FC host tools currently
70 use the following wakeup transmissions:
71
72 * On the AT command channel we send A-delay-T-delay-CR, i.e., AT and a carriage
73 return (3 characters total) with delays inserted in between; each of the two
74 delays is currently set to 30 ms based on empirical testing. We expect the
75 response to be either AT<newline>OK<newline> (echo of command followed by OK
76 response) if the modem was awake or just <newline>OK<newline> if we woke it up:
77 if we are waking the modem from deep sleep, our initial characters will trigger
78 the wakeup sequence but will themselves be lost, and the modem is expected to
79 be awake with UARTs working by the time the CR comes in; we make use of a quirk
80 of TI's AT command interpreter implementation in that sending a CR by itself
81 produces a <newline>OK<newline> response.
82
83 * On the RVTMUX interface we send a string of 64 zero bytes followed by 100 ms
84 of delay; it is certainly overkill, but this approach was implemented back in
85 2013 (near the very beginning of FreeCalypso) and has worked without any
86 problems ever since, hence we are not changing it.
87
88 In the case of RVTMUX, our serial communication engine through which everything
89 funnels is rvinterf. Rvinterf will do the "wakeup shot" the first time it sends
90 anything to the target, and for all subsequent transmissions it will consider
91 the time since the last transmission: if it is greater than a set threshold
92 (7 s by default), the wakeup shot is sent again. Thus there will be no
93 extraneous wakeup shots and associated delays during reasonably continuous
94 back to back communication, but the wakeup shot delay will be incurred if
95 rvinterf is killed and restarted or if a non-trivial pause occurs in the
96 communication flow.
97
98 In the case of AT commands, our fcup-* tools described in the User-phone-tools
99 article go through a back-end program called fcup-atinterf which does the serial
100 talking, and the latter helper program is responsible for the wakeup logic.
101 However, fcup-atinterf is not a daemon like rvinterf, it is run anew for every
102 fcup-* user command, hence every fcup-* command currently involves the wakeup
103 delay step. It is certainly inefficient, but the underlying philosophy values
104 reliability over efficiency.
105
106 The one remaining use case which has not been addressed at all yet is the GSM
107 07.10 MUX; the current plan is to investigate it after the fc-host-tools-r9
108 release and after we get FCDEV3B V2 boards which will hopefully be free from
109 the sleep mode bug that afflicts FCDEV3B V1.