I asked this yesterday but gave no useful information…
I have three modules:
1 XB24-Z7WIT-004 as Coordinator with ZigBee Coordinator API (1yr old)
1 XB24-Z7WIT-004 as ZigBee Endpoint AT (1yr old)
1 XB24-Z7UIT-004 as ZigBee Endpoint AT (new)
I updated the firmware on all three to the latest, and set them to the same PAN ID. I was able to find the two endpoint XBees and read the configuration. They were wired with only the 3.3V and ground signals. I changed the Baud rate to 115200 on all three modules and was able to talk to each through the serial port using the Sparkfun Explorer. Then I changed the sleep mode to pin mode on the two endpoints through the Coordinator link. After the first one was changed I rescanned and that one was missing. I expected that it would go to sleep. I changed the other and rescanned and it was gone, also expected.
Here is the odd part. The signals on both remotes indicate they are awake. They both have the correct voltages on all pins. But they do not respond to any outside stimulus. They used to blink the TX light on the SparkFun Explorer when I pushed the reset button, but after the change they don’t even do that. I hooked up a Commissioning button, and it does nothing. I verified with the o’scope that it was toggling the correct pin.
I went through all of the steps on the “How to fix a dead unit” page. They did not respond in any way to any step. No signal on a pin changes on the o’scope when I reset the device.
The one set up as Coordinator works exactly the way it should. It responds to commands, resets correctly, and is an all around team player. The others are bricks. Any suggestions would be appreciated.
The only way you are going to resolve this is to drive the Sleep Request line to wake the module. Then and only then will you be able to change the sleep function command. The other option is to follow the steps outlined at http://www.digi.com/support/kbase/kbaseresultdetl?id=3402 to re-write the firmware to the radio.
I tried all of that before asking. Many times. It could be that something coincidental happened, like a power spike after I made the changes but before I tried to talk directly to them. They were both on the same regulator, while the Coordinator was on the Sparkfun XBee Explorer. Anyway, I’ve ordered replacements, so it’s no problem.
Mlrlb, make sure that your DTR lines is connected all the way from the PC to the actual module so you have control over it. I think you will find that most non Digi boards simply don’t connect these lines and this is why you get into trouble when using Pin sleep.
Hi mvut,
Thanks for your reply.
After some investigating, it turned out that the DTR line is indeed not connected to the MCU.
However, I forgot to mention that we are using a custom board and the module is connected by SPI.
According to the datasheet, the SPI_SSEL pin can be used instead. But driving SPI_SSEL low does not wake up the module.
What caused the module to go into sleep in the first place, was changing the SM parameter to 1 (remotely, using XCTU).
I now have 4 sleeping modules that refuse to wake up… So any help would be appreciated!
XB24-Z7UIT-004 does not offer a SPI port. It is the S2C modules that do. On this module when using pin sleep, you must use the DTR line in order to wake the module.
To resolve your situation, you are going to need to remove the modules from your boards, re-spin the boards to add the DTR line and control it or while the modules are removed, wake the module by triggering the DTR line and then re-configuring them to use Cyclic sleep.
I’m sorry, I forgot to point out that we are using XBee-Pro 900 HP. I joined this thread because we had a similar problem, didn’t notice that dallmon used a different module.
mvut, thank you again for your time!
Have you verified that you are following the guide liens on page 34 which is as fallows:
Serial communications
XBee-PRO 900HP/XBee-PRO XSC
RF Modules User Guide 34
Figure 4:
Low power operation
Sleep modes generally work the same on SPI as they
do on UART. However, due to the addition of SPI mode, there is the option of another sleep pin, as described below:
• By default, DIO8 (SLEEP_REQUEST) is configured as a peripheral and is used for pin sleep to awaken and to sleep the radio. This applies regardless of the selected serial interface (UART or SPI).
• However, if SLEEP_REQUEST is not configured as a peripheral and SPI_SSEL is configured as a peripheral, then pin sleep is controlled by SPI_SSEL
rather than by SLEEP_REQUEST. Asserting SPI_SSEL
by driving it low either awakens the radio or keeps it awake. Negating SPI_SSEL by driving
it high puts the radio to sleep.
•Using SPI_SSEL for two purposes (to control sleep and to indicate that the SPI master has selected
a particular slave device) has the advantage of
requiring one less physical pin connection to
implement pin sleep on SPI. It has the disadvantage of putting the radio to sleep whenever the SPI master negates SPI_SSEL (meaning time will be lost waiting for the device to wake), even if that was not the intent.
