Arduino Mega not flashable with XBee PRO S2B

Question

I have an Arduino Mega 2560 with a libelium XBee Shield. If I have an XBee S2 mounted on it and set the two jumpers to the USB setting or remove them, I am able to flash a program onto my Arduino.

However, when I'm mounting one of my XBee PRO S2B (I have three of them available and all behave the same) on the Arduino, no matter how I set the jumpers, it is not possible to flash anything on it. I always see avrdude: stk500v2_getsync(): timeout communicating with programmer in the Arduino IDE.

Is the XBee PRO S2B incompatible with the Arduino or what might be the issue? I also tried to add an external power source additionally to the USB, but it didn't help either.

Update

After some more experimenting, I found out new details. I tried to disconnect each pin of the shield individually. While doing it, I discovered that disconnecting the reset pin from the arduino makes it possible to flash it - take a look at the XBee shield schematic, it's pin 5 from the ICSP connector; Photo: photo of it

I used a multimeter and discovered that the XBee PRO S2B CTS / DIO7 port is high, while the one from the XBee S2 is low, and so constantly resetting the arduino. I mounted the XBee PRO S2B onto the Sparkfun XBee Explorer USB and opened a serial port with PuTTY. In contrast to the S2, the PRO S2B provides a menu with several options:

B-Bypass Mode
F-Update App
T-Timeout
V-BL Version
A-App Version
R-Reset
>

Sparkfun XBee Explorer USB, CTS port

As soon as I type B, the CTS port goes low, and would prevent the arduino from resetting. Also this mode is needed to detect the module via XCTU. However, with an unmodified arduino, I wouldn't have a chance to send this letter, since the XBee is constantly resetting it. What is this menu, can it be disabled somehow?

• Ron J.: May seem obvious, but did you compare the register settings of the XBee S2 and S2B? Such as through X-CTU. Speed, parity, etc.
• soerface: See the update; since this DIO7 port seems to be an issue, I took a look at the configuration especially on this setting; on both, the S2 and the PRO S2B it says DIO7 Configuration: CTS flow control [1]. I suspect that all of these settings are irrelevant while it waits in this "bootloader thing"?
• Ron J.: Not a full answer - but IO/7 appears to be CTS flow control. I strongly urge you to download and use the X-CTU software (by Digi Intl.) to program them. Command line ATD7 will show current setting, ATD7=0 will disable (but use X-CTU). Why is this important? The XBee shields use CTS/RTS to signal a reboot to the Arduino (shield) - and then the bootloader will kick in and accept the data stream for flashing.
• soerface: I used X-CTU to change this setting. If I disable DIO7 [0], it shows the same behaviour - as long as it is in this bootmenu, it is high. When I enter bypass mode, it goes low. If I set DIO7 to 5 (Digital Out, High), it keeps beeing high even after choosing bypass mode. So it seems like all the settings take only effect after entering bypass mode :/
• Ron J.: Compare every setting on the working S2 with the non-working S2B thru X-CTU.

Answer 1

I don't have a PRO to play with, but I just looked at the datasheet and it appears that it SHOULD timeout after 60 seconds

If no serial transaction is initiated within a 60 second timeout period, the bootloader times out and returns to the menu. If the upload is interrupted with a power cycle or reset event, the EM250 will detect an invalid application image and enter bootloader mode. (page 139)

Also, it seems that it takes a particular set of conditions to get to the bootloader, obviously these conditions are being met:

XBee modules use a modified version of Ember’s bootloader. This bootloader version supports a custom entry mechanism that uses module pins DIN (pin 3), DTR / SLEEP_RQ (pin 9), and RTS (pin 16). To invoke the bootloader, do the following:

1. Set DTR / SLEEP_RQ low (TTL 0V) and RTS high.
2. Send a serial break to the DIN pin and power cycle or reset the module.
3. When the module powers up, DTR / SLEEP_RQ and DIN should be low (TTL 0V) and RTS should be high.
4. Terminate the serial break and send a carriage return at 115200bps to the module.
5. If successful, the module will send the Ember bootloader menu out the DOUT pin at 115200bps.
6. Commands can be sent to the bootloader at 115200bps.

Note: Hardware flow control should be disabled when entering and communicating with the EM250 bootloader.

Perhaps check pins 3, 9 and 16 on boot and see if you can modify their behaviour.

• Madivad: I've long since closed the document, but I believe the second block quote there came from page 138