After test some MicroPython scripts on my own development board, the XCTU doesn’t let me read the XBee3’s configuration, when I try to connect using MicroPython console it display this message:
Gecko Bootloader v1.8.1-RF (4144-01)
upload gbl
run
ebl info
BL >
and suddenly the Associate LED stop blink and turn off, like if it was sleeping.
BD 115200
SM No Sleep (Router)[0]
AP Api Enable MicroPhyton REPL[4]
Is this module stuck continuously in the bootloader, or does this only happen sporadically?
If this only happens sometimes, then there are a few things to watch out for. One, make sure that the DIN line is idling at 3.3V, and not at 0V (which is a BRK condition). XBee devices automatically reboot if break is held for 5+ seconds. Also, check the states of I/O lines leading to the XBee - this page describes the I/O states that force the XBee to remain at the bootloader menu. https://www.digi.com/resources/documentation/digidocs/90001539/#concepts/c_xbee_bootloader.htm
Additionally, XCTU sometimes is not able to establish communication with an XBee device if it has a MicroPython script running that is periodically outputting messages to the console (for example, printing a message every second, or printing out data as it arrives). You may want to minimize the amount of print() calls that your MicroPython code uses if you also want to use XCTU.
If the XBee is permanently stuck in the bootloader (doesn’t leave that menu after pressing the reset button or power-cycling), you will need to use the XBee Recovery menu in XCTU to apply a firmware update to recover the device. Make sure that you do not unplug the board or remove power from the XBee anytime that XCTU is attempting to do its own automatic recovery of the module - that could lead to this state.