With SM=5, pin-wake on the remote allows the remote to send data, but if there was an indirect message waiting in the base, it is not received by the remote and any subsequent messages sent by the host are also held waiting. The original waiting message and the new message may be received after the remote goes back to sleep and then wakes itself on the next cycle.
Here’s the sequence:
- remote is asleep
- base host sends message-B1 via base
- (due to separate stimulus on the remote side) remote is awakened by rising edge on sleep_rq
- remote host sends message-R1 via remote
- host receives message-R1 via base and replies with message-B2
- (remote host does NOT receive message-B1 or message-B2 at this time!)
- remote goes back to sleep
- remote wakes to check for indirect message
- remote host finally receives message-B1 and message-B2
Expected behavior:
- remote is asleep
- base host sends message-B1 via base
- (due to separate stimulus on the remote side) remote is awakened by rising edge on sleep_rq
- remote host sends message-R1 via remote and receives message-B1
- host receives message-R1 via base and replies with message-B2
- remote host receives message-B2
- remote goes back to sleep
In the application, message-R1 is a query and message-B2 is the response. It is required that there be low delay between sending the query and receiving the response. With the observed pin-wake behavior, however, the delay is ST + SP! (In the current application, this is 15 seconds! Reducing ST and SP is not a reasonable option due to the low-power requirements of the system.)
The current behavior renders pin-wake useless for 2-way communication.
(Two-way communication works fine except in the above case where there is an indirect message waiting when the pin-wake is used. In other words, it’s only a problem when the remote host and the base host both want to start a conversation at about the same time. Of course, both wanting to start a conversation at about the same time is a normal use-case in our application.)
This is all with firmware 1083 on base and remote. Is this issue addressed in a later firmware version? (The firmware release notes don’t suggest that it is.) Is there a workaround (other than greatly reducing ST and SP)?