Losing MQTT connection after setup loop

Hello,

I'm currently working on a project using an Arduino Duemilanove and the Seeed Studio W5200 ethernet shield to connect to an MQTT server I'm running on a windows PC on my local network. I'm using knolleary's PubSubClient library and the EthernetV2_0 library for all of the network code. It's probably worth mentioning I'm also using a NRF24L01 transceiver radio, and because of issues trying to use multiple SPI devices with the Ethernet shield, I was forced to use software SPI in order to attempt to use both devices. For that I used the SoftSPI functionality of TMRH20's RF24 library. This is where my issues started, I can run the example code for a MQTT client perfectly fine, but as soon as I added the radio libraries (even if I don't initialize it or call any functions), I started having issues connecting to the MQTT server outside of the setup loop. Initializing the Ethernet connection using dhcp works fine, and the first connection and publishing to the MQTT server also works, but as soon as the program enters the loop code, I get a socket read error on the MQTT server (on the log from my computer running the sever) and the arduino client disconnects, and fails to reconnect indefinitely. The error code I'm getting from the PubSubLibrary is -2, which from what I understand indicates an error while attempting to establish a connection to the broker, which I believe means theres an issue with implementing the Ethernet library somewhere. The main problem is that I don't know why it works during setup, but then breaks as soon as the main loop is initialized. If anyone has any advice on what to test, or try to change, I've included the test code I've been working with to try to find the issue.

include

include

include

include

include

include

include

include "printf.h"

define SDCARD_CS 4

byte mac[] = {0xDE, 0xED, 0xBA, 0xFE, 0xFE, 0xED}; IPAddress ip(192, 168, 0, 37); IPAddress server(192, 168, 0, 34); EthernetClient ethClient; PubSubClient client(ethClient);

RF24 radio(5,6); const uint64_t pipes[2] = {0xF0F0F0F0AA, 0xF0F0F0F0BB};

void reconnect() { while (!client.connected()) { Serial.print("Attempting MQTT connection..."); if (client.connect("arduinoClient")) { Serial.println("connected"); client.publish("openhab/Gateway","Receive Gateway reporting in"); client.subscribe("openhab/Command"); } else { Serial.print("failed, rc="); Serial.print(client.state()); Serial.println(" try again in 5 seconds"); delay(5000); } } }

void setup() { pinMode(SDCARD_CS,OUTPUT); digitalWrite(SDCARD_CS, HIGH); Serial.begin(9600);

radio.begin(); radio.setRetries(15,15); radio.enableDynamicPayloads(); radio.openReadingPipe(1,pipes[0]); radio.printDetails(); radio.startListening();

client.setServer("192.168.0.34", 1883); client.setCallback(callback); Ethernet.begin(mac); delay(1500); Serial.println(Ethernet.localIP()); reconnect(); Serial.println(client.state()); }

void loop() { if (!client.connected()) { reconnect(); } client.loop(); Serial.println(client.state()); if(millis() - sensorTime > 5000){ boolean ok = client.publish("openhab/test", "test"); Serial.println(ok); sensorTime = millis(); }

if(radio.available()){ int buf; radio.read(&buf, radio.getPayloadSize()); Serial.println(buf); } }

This construct is quite dangerous:

if(radio.available()){
    int buf;
    radio.read(&buf, radio.getPayloadSize());
    Serial.println(buf);
  }

If radio.getPayloadSize() returns something greater than 2 bytes, it will overwrite something past buf. Try this to see if your problem goes away:

radio.read(&buf, 2); // was radio.getPayloadSize()

Thanks for pointing that out, I was working with variable payload sizes at one point and had forgotten to change the variable size to my max payload size. It turns out that wasn't the main issue though as I was only sending 2 byte payloads when I was running the code anyways. What ended up being the cause of all my connection problems was a pin definition that I had mistakenly made elsewhere in my code for the same pin that was the SPI select pin for the SD card reader that is a part of the Ethernet shield. When I was setting that pin to low, I was also switching SPI devices which was breaking my network connection, and the reconnects were failing because I was never setting the pin high again to deselect it. Lesson learned, always check those pesky definitions first.