Hanging up on send

[dclobato]

Hi,

I have a code that was working nice until three weeks ago, when I was on version <0.6.0 of this library and on Arduino 1.6.5. Now, I'm on version 0.6.0 and Arduino 1.6.6. The hardware is a Arduino Mega.

Now, everytime I try to send something (e.g., the sample code of Series2_Tx or the code sample below), there is no activity on radio (the transmission LED on my Xbee shield does not blink). If I remove the radio and connect it on a FTDI cable, I can send data flawless using XCTU -- so, I believe the radio and the shield are ok.

#define NODEiD "Node1"
XBee radio = XBee();
XBeeAddress64 destino = XBeeAddress64(0x0013a200, 0x40c6740d);
char toSend[50];

ZBTxStatusResponse sendToNode(XBee radio, XBeeAddress64 to, char *s)
{
  ZBTxRequest zbTx;
  ZBTxStatusResponse txStatus;

  zbTx = ZBTxRequest(to, (uint8_t *) s, strlen(s));
  radio.send(zbTx);
  txStatus = ZBTxStatusResponse();

  return (txStatus);
}

void setup() {
  ZBTxStatusResponse txStatus;

  Serial3.begin(9600);
  radio.setSerial(Serial3);
  createMessage (toSend, 50, "ON", NODEiD, 0); // A procedure to fill toSend with data to be sent
  txStatus = sendToNode(radio, destino, toSend);
}

void loop() {
}

After some debugging, I traced down to line 1547 of XBee.cpp (flush();). When the execution flow reaches that line, the code hangs up.

Any idea on what is going on?

[dclobato]

After posting this, I went to Arduino Github and found this bug

https://github.com/arduino/Arduino/issues/4029

Maybe it is related to the problem I'm experiencing?

[davidsainty]

That flush() shouldn't be there in my opinion. I think there was an issue relating to that on the old Google Code site, not sure here.

I patch it out when I use the library.

Arduino's Serial flush() doesn't have a reliable interface. It either dumps the input buffer (definitely not useful here), or waits for all data to be sent (extremely questionable use here - the library really shouldn't block). There's no contract. Sadly the Arduino serial libraries have always been very crappy in terms of having any way of interrogating and managing the state of the serial buffers.

But I don't see why it should cause your problem - your problem seems to be that serial transmission isn't happening? Maybe your libraries do something different again on a flush() - dump the output buffer contents?

[dclobato]

So if I create a pull request removing flush(), it will be fine?

edit: about your question, I really do not know what is going on the serial... The XBee was working fine yesterday and, today, after updating the sketch, it stopped working again. I have other serial devices connected on the MEGA's Serial1 and Serial2, and I'm using XBee on Serial3. It is kind of a random issue...

Anyway, removed flush() and will do another test: I'm in class right now :-P

[davidsainty]

Does removing the flush fix your problem?

WRT a pull request:

I can confirm it works fine with no flush() and either AltSoftSerial or HardwareSerial - the two Serial types I use with this library. With old SoftwareSerial() it is also fine, since every serial byte output is flushed. With at least one of those libraries, calling flush() screws up the received data stream, so removing it is mandatory.

I tend to think that anyone that really wants a flush to happen can call it themselves. Especially since flush() does different things with different libraries, only the integrating programmer knows for sure if it's the right thing to do. So I'd be in favour of the library doing no explicit flushing at all...

[matthijskooijman]

@davidsainty, agreed that removing flush is a good idea. I can't really explain why having it in the first place would lock up, though, AFAICS flush() is properly implemented in HardwareSerial.

[andrewrapp]

I merged the pull request that removes flush. Thanks guys!