The XBee Pro S3B works great with the Pi except for one major issue. I’m required to use the GPIO pins instead of the USB, which, unfortunately, is the only time this happens.
I’m using the following shield to interface with the Pi:
When I Boot up the Pi, after the power has been completely cut, the XBee module starts out unresponsive(when I used the adapter that Digi provided, same issue, and none of the LEDs came on). If I then unplug the Shield and plug it back in it comes on and works perfectly. This is my only obstacle to using this shield so any help you could provide would be helpful.
I figured out how to get it going via hardware. If I short the reset pin(5) to ground and then release it, it wakes up. I was hoping to do it via software. I tried making the line go with the GPIO, but it doesn’t seem to work.
You can fix this via software by disabling UART output in cmdline and setting BOOT_UART to zero.
Example for Pi 5:
sudo rpi-eeprom-config --edit
BOOT_UART=0
My guess is that this is an issue due to the firmware version installed. You likely have the XSC firmware installed. If that is the case, make sure that Pin 6 is not connected or change the firmware to the 200 K HP firmware.
Ah yeah, this is a classic power sequencing quirk with certain Pi GPIO expansion shields. Because the Pi’s 3.3V rail and GPIO pins power up instantly or float during early boot, the XBee’s internal logic can get stuck in a weird half-latched state until it sees a hard power cycle or a manual reset pulse.
Like the other guys mentioned, dealing with it via a software config tweak on the UART or handling the reset pin logic usually clears it up permanently. You can check here for some additional documentation notes on similar hardware handshake troubleshooting techniques if you’re trying to avoid manual intervention every time you reboot the system.
One thing worth checking is which pin you use to drive RESET: XBee reset is active low and the module has an internal pull-up, so the Pi should only pull it low briefly and then release it (set the GPIO back to input) rather than driving it high. Also, do you know which firmware and baud rate the module is on? A short low pulse on RESET during Pi boot, after the UART is up, might remove the need to re-seat the shield.