I used a network of 2 XBee 3 endpoints with firmware version “1009” and coordinator XBee3 PRO. The controller communicates via AT commands via the UART interface with the XBee module. The device performs the following algorithm:
Measure:
Send “SN” AT command with 0x0F value;
Send “ST” AT command with 0x1388 value;
Send “SP” AT command with 0x0AF0 value;
Send “SI” AT command;
Do measurements;
Send “SP” AT command with 0x0AF0 value;
Send “D5” AT command with 0x0500 value;
Send “AS” AT command;
Wait 3 sec;
Send “D5” AT command with 0x0400 value;
Send “SI” AT command;
Send:
Send “SN” AT command with 0x01 value;
Send “ST” AT command with 0x20 value;
Send “SP” AT command with 0x20 value;
Transmit data to coordinator;
Wait for 2 hours (aka active load):
Send “AS” AT command;
Delay 10 sec;
The CTS pin is used to control data transmission, and the RTS is pulled to the ground (I attached the settings profile). At some point, one device stopped sending data and started debag through the controller. The CTS pin was in the upper state, the DTR was in the lower state (it is lowered every time an AT command is sent). Then I tried to lower the “Reset” pin by 0.2, 1 and 10 seconds and raise it again. The module does not react in any way, although I can clearly see on the oscilloscope that the reset is happening. Then I de-energized the device and turned it on a minute later - the module has started working. However, a couple of days later the situation repeated and then I updated the firmware to version “1010” and still there were no sucks on these devices (a month has passed).
But I added 5 new endpoints to the system with the latest version of the XBee firmware “1010” and the same situation occurred on 3 of them a couple of days later. I have restarted 2 of them, and one is still in a “dead” state for tests.
How can I get the device out of this state without turning off the power? And what could have caused this?
Can I somehow diagnose that this module is clearly in bootloader mode? I tried to connect via UART with a 115200 baud rate and send “\r”, but the device does not respond in any way. TTL levels are 3.3V and 0V.
I checked all the variants of the baud rate starting from 110 to 921600. The device is not responding. Is there any other way I can make sure this is bootloader mode?
Let me remind you that the RTS line is pulled down on the XBee side, but the instructions say that it is necessary to create a high level there to switch to the bootloader.
I also tried the recovery tool in the XCTU program, however, I received this message.
At the same time, if I de-energize the radio and turn it on again, it will work properly (until the next failure).
There was indeed a small excess of VCC (3630mV) on the tested devices. Then I connected a DC-DC step-down with an average voltage of 3050mV (there were flat line on the oscilloscope) to the new XBee 3 module. Two weeks without freezing. But module from the previous test continued to freeze periodically, even though it had the latest firmware version. I swapped the XBee modules and a day later I got freezing on the old XBee 3 with DC-DC power.
So your conditions are met, although the device still froze. Could you please advise what else could be the issue?
Operating the device outside of specifications can cause damage to the module. As a result, I can’t say if it has been damaged or not and that could be what is now causing it.
We launched a new test with absolutely new 10 modules with exactly the same algorithm of actions from a stabilized 3V voltage source and encountered the same behavior on one module 3 days later.
Do you have any suggestions what else could have caused the dead freeze? What additional data can I provide to you?
I would suggest opening a case with Digi Support. When doing so, please provide as much information as you can. Also make sure before you do that you can reproduce this issue with using a Digi Interface board.
Hello,
I am experiencing the same problem. We have more than 10 modules and after several days. Some module stop working and are in “dead” state. Sometimes the module restart and work again. Can you let me know how you fix this problem and what is the cause ?
After this problem, the library for communicating with the XBee module over UART was completely rewritten, so I don’t know the exact cause of the hangs then.
However, the few days ago I encountered that the AS(Active Scan) command sometimes fails to respond and after that the response to AS is always with an error code. I described this issue here. I think in this case there was the same error, but at that time I didn’t know how to keep track of such situations.
Now I am testing a new solution - when there are many errors in a row for AS command, I send FR(Software Reset) command and wait for module reset. So far it works, but I would like to know the exact cause of such behavior of AS command.
Hello, thanks for your replies. We contact the digi support. In parallel, we are trying to catch the communication when the module go in the dead state. However, it’s random and not frequent (several days…). I hope to see some errors.
It will be interesting to know the cause. It is not normal after hardware reset, the module is still in the dead state.
