Programming Arduino Wirelessly - Faludi method

Forum 2005-2010 (read only) Hardware Troubleshooting
1

I may be jumping too early to get help here, but it may save me some hours (days?).
I am trying to follow Rob Faludi's course for programming arduino wirelessly, through XBee.
Here is the article:
http://www.faludi.com/itp_coursework/meshnetworking/XBee/XBee_program_Arduino_wireless.html

My 2 XBees are talking to each other fine (I checked).
All is good up to the point of (after) reset, when the bootloader is supposed to start loading the sketch. I see the (old) sketch starting very fast (less than 1 second) after the reset. The LED on pin 13 does a quick flash, then the sketch start to run. It seems that the bootloader never has the chance to read the serial port.

Arduino IDE reports error

Binary sketch size: 3328 bytes (of a 14336 byte maximum)
avrdude: stk500_getsync(): not in sync: resp=0x20
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x20

I had tried communication speeds of 19,200 (as in the article), for atmega 168, as well as 57,600, with atmega 328. Same behaviour in both cases, the old sketch is restarted right after reset.

This is the sketch I am using, a modified version of the one in the article.

/* Programming Arduino Wirelessly
 * ------------
 * This program waits for a *reset serial message from a remote computer,
 * then resets the Arduino chip after a delay to allow the microcontroller to
 * accept an upload of new code from a remote device.
 * Robert Faludi
 * rob@faludi.com
 */
int ledPin = 13; // LED connected to digital pin
int transistorPin = 14;  // analog 0 = digital 14

unsigned long lastTime = 0;
unsigned long counter  = 0;


void setup()
{
   pinMode(ledPin, OUTPUT); // sets the digital pin as output
   pinMode(transistorPin, OUTPUT);

//   Serial.begin(57600); // start serial at 57600 baud, same as programmer speed
   Serial.begin(19200); // start serial at 19200 baud, same as programmer speed
   Serial.println("Just started after reset");
}


void loop()
{
  ping();
  
  if ( Serial.available() > 1)
  {
    // if there are bytes waiting on the serial port
    char inByte = Serial.read(); // read a byte
    Serial.print(inByte);

    if (inByte == '*')
    {
       char cmdChar = Serial.read();
       Serial.print(cmdChar);
       if (cmdChar == 'r')
         resetChip(5000); // reset the chip after waiting for the specified # of milliseconds
    }
  }
}

                                 
void resetChip(int delayTime)
{
   /* if the project does not typically receive data, and accidental chip resets are tolerable,
   * this is a simple method that should work just fine. Otherwise it is recommended that the 
   * reset request string be part of a call-response sequence, be transmitted with a
   * reserved byte or byte string, or be transmitted in some way out of band, so that it is not 
   * accidentally received.
   */
   Serial.print("\nArduino will reset in ");
   Serial.print(delayTime/1000, DEC);
   Serial.print(" seconds... Disconnect hyperterminal, then prepare to upload sketch.\n\r");
   Serial.print("\nResetting NOW. Should upload the sketch.\n\r");
   digitalWrite(transistorPin, HIGH); // switch on a transistor that pulls the chip's reset pin to ground
   delay(1000);  // not really useful here;
}


// ping every 5 seconds;
void ping()
{
  if (abs(millis() - lastTime) < 5000)
    return;

  counter++;
  Serial.print("ping ");
  Serial.println(counter);

  lastTime = millis();
}

This is how the hyperterminal session looks like:

I was wondering if anybody had any success with this method.

Could this be caused by the unorthodox reset (output pin 14 connected to reset pin)? The uC seems to properly reset though, the sketch is restarted fresh.

Any help is appreciated.
Thanks.
FlorinC

2 
Could this be caused by the unorthodox reset (output pin 14 connected to reset pin)? The uC seems to properly reset though, the sketch is restarted fresh.

That method of performing an external reset has been discussed here before and the bottom line was that the AVR data sheet expressively cautions about not using it because the minimum duration of a reset pulse cannot be obtained once the AVR tri-states all it's data pins during the start of the hardware reset process.

Lefty

3

Thanks.

I did some more investigation and it seems to be unrelated to the "self reset" method.
When I (manually) press the reset button, I would expect the behaviour to be similar to a non-wireless board, that is, immediately after the reset, the bootloader should start reading the serial port for an upcoming sketch. That does not happen, I get the same error.

So, at this point, I am sure that the "self reset" is not the culprit here.