Table of Contents
Advertisement
3.8
Application Wake-up
The wake-up mechanism is a feature provided by the CM52 where the CM52 can remain powered on and
function as a module without the host application being powered on. This type of configuration is primarily
done for power consumption purposes. The CM52 will assert a hardware line when events previously
specified by the application occur within the module. The hardware line is a trigger for the host application to
power up and process the event.
3.8.1
Details
The host application can indicate to the CM52 which events it wishes to be notified of by using
AT*EWAKESET. The host application can then power down, leaving the CM52 powered on. The host
application needs to monitor the CM52's Ring Indicator (RI) hardware pin. The RI is asserted when the
module is handling an event that the host application specified. When the RI is asserted, the host application
should power up and immediately query for the wakeup reason by using AT*EWAKE. Given the reason for
wakeup, the host application can process the event(s) accordingly:
•
In the case of an incoming call (voice or data), the call can be immediately answered. Note an
incoming call will remain active only for a limited period if it is not answered. It is recommended not to
delay answering because the call could go to voicemail. If the caller ID is used in determining whether
to answer the call, the module can be queried for the caller ID using AT*ECALLERID.
•
In the case of an incoming SMS message, the host application can query for temporarily stored SMS
messages using AT+CSLM. AT+CSLM will return all stored messages. If the host application is
interested only in a specific message type, such as text or binary, and should not be woken up for other
message types, SMS filtering can be used. Refer to AT*ESMSFLTR for more details.
•
In the case of an Antenna failure, the host application must use AT*EAFF to correct the situation.
•
In the case of Antenna Diagnostic notification, the host application can use AT*EANTDIAG to
determine the current state of the antenna and take appropriate action (for instance switching to the
other antenna).
•
In the case of the RTC cycle completion, the host application can handle as needed.
•
In the case of voice mail notification, the host application can handle as needed.
•
In the case of service change (including no service) notification, the host application can handle as
needed.
All the necessary information to address the wakeup events can be accounted for, either in the event itself or
retrieved by querying the module. There is no relevant historical data (unsolicited messages) that would be of
benefit to addressing the wakeup events.
3.8.2
Behavior
After an event has triggered the RI, the event will NOT be reset if the event is canceled. An example would be
when an incoming call triggers the RI, but then the call is dropped. The application has to account for the case
where the event may no longer be valid.
Multiple event types can occur between the first event and when the application queries for the event reason.
All event types will be OR'ed together. As a result, querying for the wakeup reason could produce more than
one action.
Once wakeup events are specified by that application, the RI and wakeup reason will be set for any event
regardless of whether the application is powered on. The CM52 has cannot detect when the application is not
powered on; therefore, the application must control the setting, actually resetting the wakeup reason. The
issue is that the application must ensure the wakeup reason is set to zero before the application powers down.
Otherwise, when the application powers on, events from the last power cycle could be present. This can
easily be accomplished by querying the wakeup reasons immediately before powering down (AT*EWAKE
resets the wakeup reason to zero or none)
Confidential
USERS MANUAL
Document number
1/198 17-4/FCP 101 3045 Uen
24(158)
Revision
D
Advertisement
Table of Contents
