inconsistent behaviour with arduinoIsp

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have an arduino uno set up as an isp. From the arduino ide I can write a sketch and download to a uc connected to the isp. A

If I write a program in studio and then try and program the ttarget connected to the isp....... I actually reprogram the isp rather than the target! The command line for avrdude is identical in both cases.

I have read of needing a 10uF cap but as all works well from the ide I have not tried it.

Any suggestions?

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got the ArduinoISP program working without using the suggested cap. I remember that it was easy to get confused as to which AVR you were actually programming - the one on the Arduino that becomes the ArduinoISP or the one being programmed by the ArduinoISP. I had to reread the instructions to get it right. But I didn't try using an externally generated .hex file from studio so I can't comment on that.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gregd99 wrote:
I have read of needing a 10uF cap but as all works well from the ide I have not tried it.

Any suggestions?

Try the cap :)

I've never gotten ArduinoISP to work withoutthe cap on reset. Why it ever worked for you is a good question, but it is important to have it.

JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You used a 10uF cap on the reset? A 100nF with a 10k pullup maybe, but 10uF?

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
You used a 10uF cap on the reset? A 100nF with a 10k pullup maybe, but 10uF?
The cap is meant to go across |RESET and GND, and defeats the reset pulse from DTR. That reset pulse is meant to reset the AVR on the Arduino to run the bootloader. You need to defeat this behaviour when using ArduinoISP.

In practice, I've used a 1 uF successfully. I doubt 100 nF would work reliably.

JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

None of the circuits in the ArduinoISP web page show the use of a capacitor:
http://arduino.cc/en/Tutorial/Ar...

When I use an FTDI breakout board to program an Arduino, I use a 100nF cap between DTR and reset with a 10K pullup on reset. This is to put the AVR into the Arduino bootloader mode.

Using ArduinoISP is different in that it cause the master arduino to generate the ISP signals needed to program a slave AVR. No capacitor is indicated for this reset in the original documents and I've not needed any capacitor to do this in my version of the ArduinoISP.

Maybe a 10uF across Vcc and GND would help if you've got an iffy power supply.

I'm not sure what a 10uF cap would do across reset and ground other than delay the signal and keep it high for a while after it is shut down.

So we have two different uses for the reset pin, in one you are putting the AVR in the bootloader mode and the program is uploaded via the TXD and RXD pins. In the other, the reset is used for the ISP program upload which goes through the SPI pins. The former can use a small cap, the latter doesn't need one. Apples and Oranges.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the problem?

Talk to UNO bootloader:

avrdude -c arduino -P com12 -b 115200 -p ATmega328P

Using ArduinoISP:

avrdude -c stk500v1 -P com12 -b 19200 -p ATmega328P

The first one uses a completely different baudrate.
The second one should still work even if the DTR line 'resets' the ArduinoISP sketch.

I can see some ambiguity if you were to recompile ArduinoISP.ino sketch to run at 115200 baud.

Yes, some old Arduino bootloaders run at 19200 baud. So it would be wise to recompile ArduinoISP to use a different baud rate.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The theory is as david says: by running arduinoISP at a different baudrate than the bootloader, the initial autoreset doesn't matter - avrdude sends commands to the bootloader but it ignores them (because they are at the wrong speed, so it doesn't recognize them), and starts running the arduinoISP sketch, which DOES recognize them.

There are a couple of problems with this theory:
1) Original Arduino Unos shipped with a version of optiboot that would keep running the bootloader in the presence of ANY serial traffic, recognizable or not. (http://code.google.com/p/arduino... )

2) The bootloader timeout and the avrdude timeout/retry algorithms need to be compatible.

I've always had better luck using ArduinoISP on an Arduino that has the autoreset disabled (using the cap, or using an older, pre-autoreset board.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
None of the circuits in the ArduinoISP web page show the use of a capacitor:
http://arduino.cc/en/Tutorial/Ar...
So I guess you missed point #5:
Quote:
5. Wire your Arduino board to the target as shown in the diagram below. (Note for the Arduino Uno: you'll need to add a 10 uF capacitor between reset and ground.)
And the caption to the first image:
Quote:
On the Arduino Uno, you'll need to connect a 10 uF capacitor between reset and ground (after uploading the ArduinoISP sketch).
JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have read enough from the comments above to make me question whether what I (thought I) observed is correct. ie IDE wrote to slave but command line wrote to Uno. I will go back and verify this evening.

the cap discussion still confuses me and I wonder if it is historic.

If I look at the avrdude code - see below - the "ardunio" programmer option explicitly resets the Uno by asserting DTR (and RTS just in case). This resets the Uno which then starts in bootloader mode and accepts the program comms to write the uno flash.

The "stk500" option (presume this is same as stk500v1) does not reset the device so the arduinoIsp sketch will keep running and be ready to accept data and send on via the SPI to the slave device.

If the statements above are correct then does the cap still serve a purpose?

static int arduino_open(PROGRAMMER * pgm, char * port)
{
  strcpy(pgm->port, port);
  if (serial_open(port, pgm->baudrate? pgm->baudrate: 115200, &pgm->fd)==-1) {
    return -1;
  }

  /* Clear DTR and RTS to unload the RESET capacitor 
   * (for example in Arduino) */
  serial_set_dtr_rts(&pgm->fd, 0);
  usleep(50*1000);
  /* Set DTR and RTS back to high */
  serial_set_dtr_rts(&pgm->fd, 1);
  usleep(50*1000);

  /*
   * drain any extraneous input
   */
  stk500_drain(pgm, 0);

  if (stk500_getsync(pgm) < 0)
    return -1;

  return 0;
}
static int stk500_open(PROGRAMMER * pgm, char * port)
{
  strcpy(pgm->port, port);
  if (serial_open(port, pgm->baudrate? pgm->baudrate: 115200, &pgm->fd)==-1) {
    return -1;
  }

  /*
   * drain any extraneous input
   */
  stk500_drain(pgm, 0);

  // MIB510 init
  if (strcmp(ldata(lfirst(pgm->id)), "mib510") == 0 &&
      mib510_isp(pgm, 1) != 0)
    return -1;

  if (stk500_getsync(pgm) < 0)
    return -1;

  return 0;
}

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
smileymicros wrote:
None of the circuits in the ArduinoISP web page show the use of a capacitor:
http://arduino.cc/en/Tutorial/Ar...
So I guess you missed point #5:
Quote:
5. Wire your Arduino board to the target as shown in the diagram below. (Note for the Arduino Uno: you'll need to add a 10 uF capacitor between reset and ground.)
And the caption to the first image:
Quote:
On the Arduino Uno, you'll need to connect a 10 uF capacitor between reset and ground (after uploading the ArduinoISP sketch).
JJ
Yup, missed those.

I'm going to have to look a bit deeper at this using the UNO. I thought I used the UNO with no problem, but maybe I got lucky.

Sorry,
Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
I'm going to have to look a bit deeper at this using the UNO. I thought I used the UNO with no problem, but maybe I got lucky.

Sorry,
Smiley

Don't be.

I dug a bit deeper myself. I did in fact manage to get avrdude to connect to the ArduinoISP on an UNO without a capacitor across RESET and GND... much to my surprise.

When I'd tried this some months ago I'd had no luck. It seemed avrdude was timing out before the ArduinoISP could respond, due to the delay imposed by the UNO reset and bootloader running. At the time I saw similar behaviour with the Arduino IDE (1.0).

I don't know what I did differently to make it work now. I haven't yet confirmed the behaviour under the Arduino IDE.

JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
the "ardunio" programmer option explicitly resets the Uno by asserting DTR (and RTS just in case).

Yes. Asserting both allows use of different USB-Serial adapters, that break out different signals.

Quote:
This resets the Uno which then starts in bootloader mode and accepts the program comms to write the uno flash.

Yes, but the bootloader accepts comms at 115200bps; if you're using arduinoISP, you should have given avrdude a command to set the speed to 19200bps. (Note that 115200 is the default speed for stk500-like programmers, I think.)

Quote:
The "stk500" option (presume this is same as stk500v1)

Yes.

Quote:
does not reset the device so the arduinoIsp sketch will keep running and be ready to accept data and send on via the SPI to the slave device.

"maybe." The thing is; opening the serial port on the host OS can cause RTS/DTR to change state and trigger an auto-reset. This depends on which version of which OS, and which version of avrdude, and perhaps which comm port driver and comm port hardware you have. Originally, there was no -carduino option, and the whole auto-reset feature depended on this side-effect of opening the port. In later versions, the dtr/rts toggling was made explicit.

Quote:
If the statements above are correct then does the cap still serve a purpose?

The cap prevents the RTS/DTR signal changes from propagating to the RESET of the AVR, regardless of whether they were caused by side-effect or explicit code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

after re-investigating I can report a very silly mistake..... the led that I was monitoring on my target to verify the download OK was correctly referenced in the arduino code.... but wrongly referenced in the studio code.

everything was actually working OK all along :oops:

in the end.... using the stk500v1 programmer type and the arduinoISP sketch I am able to programme from the arduino IDE or from the the command line with code generated by either the arduino environment or raw code from studio.

I have not added any caps and all is well. whether this is a fluke with my particular Uno (rev 3 I think) or not I don't know.

Thanks to all for the valuable info.

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
The theory is as david says: by running arduinoISP at a different baudrate than the bootloader, the initial autoreset doesn't matter - avrdude sends commands to the bootloader but it ignores them (because they are at the wrong speed, so it doesn't recognize them), and starts running the arduinoISP sketch, which DOES recognize them.

There are a couple of problems with this theory:
1) Original Arduino Unos shipped with a version of optiboot that would keep running the bootloader in the presence of ANY serial traffic, recognizable or not. (http://code.google.com/p/arduino... )

2) The bootloader timeout and the avrdude timeout/retry algorithms need to be compatible.

I've always had better luck using ArduinoISP on an Arduino that has the autoreset disabled (using the cap, or using an older, pre-autoreset board.)

It should be possible to identify which release of optiboot is present on a punter's UNO. e.g. calculate a CRC.

I have run ArduinoISP on several different Arduinos and with several Arduino releases. I have never had a problem.

There are a finite number of official Arduino releases. So it should not be too difficult to make a definitive report about any optiboot+arduino problem.

I really can't see that a capacitor is necessary.

David.