We have had over 50 XBee S1 modules fail over the last six months. The modules are in a fleet of over 300 devices and failing randomly. The returned modules can be recovered using XCTU, but until we understand why they are failing we cannot return them to service.
We use these devices in transparent mode to transmit data to a PC using a XStick in an indoor application. We configure the modules for baud, channel, and sleep mode at power up with our PIC18 based device using the “backdoor” hold DIN low at power to enter Command Mode. When the modules fail they do not respond and instead output a constant 4.169kHz clock like signal on the DOUT pin (I can send logic analyzer scan if needed). We have been using these modules for years with the same firmware (ours and the modules) without this issue. We, and Digi tech support, are at a loss to figure this one out. Any help would be greatly appreciated.
I think I know what is going on. If you switch to using the +++ method of entering command mode, I suspect you will not have this issue.
Unfortunately we don’t have that option as this is a medical device and any changes in firmware require recertification. We have been replacing the failed S1’s with S2C’s, but we have over 8000 devices in service and this swap is not very cost effective. Do you think it is entering bootloader mode and corrupting the firmware? They bricked devices do not respond to a power cycle and must be recovered using XCTU with a dev board. Thanks for your response.
What I think is going on is that you are inadvertently entering command mode. Then the data you are sending is confusing the radio or causing issues and or corrupting the firmware. This is why I think the change would help prevent this from happening.