Wavecom GR64 Application Note - page 17
2.4.5
Wireless CPU® Repeats Attempts to Initiate Sleep
In this example, the Wireless CPU® attempts to initiate sleep through the normal flow
control mechanism, but the Host fails to acknowledge within the time-out period for
repeated attempts.
Figure 6.
Wireless CPU® attempts sleep initiation, Host fails to acknowledge
Time Description
1
A data transfer between the Host and the Wireless CPU® is completed.
2
The Wireless CPU® has nothing further to communicate to the Host and requests
sleep by de-assertion of DSR1 and CTS1. The Host does not acknowledge the
request before the time-out period
a
(500ms) has expired and subsequently re-
asserts DSR1 and CTS1 for the programmable period
b
.
3
The Wireless CPU® makes a second attempt to request sleep by de-assertion of
DSR1 and CTS1. The Host does not acknowledge the request before the time-out
period
a
has expired and subsequently re-asserts DSR1 and CTS1 for the period
b
.
4
The Wireless CPU® makes a third attempt to request sleep by de-assertion of DSR1
and CTS1. Once again, the Host fails to acknowledge the request before the time-
out period
a
has expired and subsequently re-asserts DSR1 and CTS1.
5
At this point three failed attempts have been made by the Wireless CPU® to initiate
sleep, so no further attempt is made (the status of standby handshake can be
queried with AT*E2RS232?)
6
The UARTs remain active, and data flow can continue at any point in time after the
final attempt at initiating sleep.
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 17/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable