I am using the Digi XBee-PRO DigiMesh 2.4 RF module in an embedded application. It is using an Atmel Xmega 8-bit microprocessor as a host processor. I use the Digi modules DIN/DOUT lines for serial UART communications with the Xmega host processor, RTS/CTS for flow control, and SLEEP_RQ (pin 9) and SLEEP (pin 13) pins for controlling and detecting the sleep state of the Digi module. I am using asynchronous pin sleep mode (SM = 1) and am configuring CE=2 (end device) D8=3 (DIO8/SLEEP_RQ pin as digital input, monitored) and D9=1(DIO9/ON/SLEEP as ON/SLEEP status pin) on the Digi module.
The device operation is as follows. The device sends a message to our server via a Digi ConnectPort X2 gateway, at random times, but on average once every 2 seconds. The host processor wakes up the Digi module when it needs to send a message to our server by pulling the SLEEP_RQ pin low. It then sends the message to the Digi module over the UART (using API frames). When done with sending the message over the UART, the host processor pulls the SLEEP_RQ pin high to put it to sleep again. The Digi module stays asleep till the host processor needs to send another message to our server.
This seems to work for arbitrary lengths of time, sometimes for an hour or two, sometimes even over a day, but eventually, the Digi module gets into a state where it no longer wakes up, even through the SLEEP_RQ line is constantly pulled low by the host processor. This is obvious as the SLEEP status pin on the Digi module continues to stay low, indicating that it is stuck in sleep mode.
In this stuck in sleep mode state, if I force the SLEEP_RQ pin to toggle high and then low, the Digi module recovers and is able to start working normally again.
Can anyone please shed some light on why the Digi module gets stuck in sleep mode, and what can be possibly be done to avoid it. Are there any timing requirements that must be followed when pulling SLEEP_RQ low or high?
I seem to have a work-around for the above issue where the Digi module gets stuck in sleep state. Its not really a solution to the problem, as I think the Digi module should be robust enough to avoid getting into a state where pulling the SLEEP_RQ low line does not wake up the Digi module.
The work-around is that I am now monitoring the ON/SLEEP pin (pin 13) output line from the Digi module in my application. Now when I try to wake up the Digi module, I pull the SLEEP_RQ line low and wait for the ON/SLEEP output from the Digi module to indicate that the device is indeed awake (pin is high). If the ON/SLEEP pin does not indicate that the module is awake within my specified timeout (250ms), I toggle the SLEEP_RQ line high and then low again. This ensures that the Digi module quickly recovers if it does get stuck in sleep state. With this change in place, I have not seen the Digi module getting stuck in sleep state with testing with a couple of devices over two days.
After the change described above with monitoring the ON/SLEEP pin, I have not seen the device getting stuck in sleep mode (even with the SLEEP_RQ being pulled low). I have however encountered another issue now.
One of my Digi modules got into a state where the Digi module was hung - only this time the ON/SLEEP pin was high, indicating that the module was awake when it got hung. The SLEEP_RQ line was still being held low by my host processor as it was trying to send a message to the gateway/server and the CTS line was high, indicating that the module’s tx buffer was full. However, the module was unable to send or receive anything over the air. I tried to perform a network discovery from the gateway, but the hanging Digi module did not show up as a discover-able node. Trying to send an “Identify” command from the Digi gateway to the hanging Digi module resulted in a “Device not responding” error message on the gateway web interface.
In this case, toggling the SLEEP_RQ line did not have any effect. The Digi RESET line had to be pulled low momentarily to reset the device, after which it started working normally again.
yes, I have been able to replicate the issue with the latest 8x70 firmware as well.
I had 3 boards running overnight, over an approximately 12 hour period. Two of my modules, got into the “stuck in sleep” mode 3 times each, whereas the third one got into this state 8 times over this period. As explained in my original post, I can get the Digi module to recover by toggling the SLEEP_RQ high and then low when it gets into this “stuck in sleep” mode state.
Furthermore, one of the devices, after toggling the SLEEP_RQ line when it was in the “stuck in sleep” mode for the third time, became completely unresponsive. It needed a reset to start working again.