Arduino as ISP strange problem

Projects Programming
1

Hi all,

I've been trying to convert the "stock" "Arduino as ISP" sketch to use a bit-bang SPI driver so that a shield such as the Sparkfun AVR ISP board will work with an UNO board as well as a MEGA 2560 board.

The code works perfectly with an UNO, but not on a MEGA.

Note that I am NOT using the hardware SPI, so it's not the "13,12,11,10" vs "53,52,51,50" thing.

I tracked the problem down to the SERIAL PORT!

In the loop that watches the serial port:

if (Serial.available()) {
    debug("got serial data");
    avrisp();
}

Clicking "Burn Bootloader" in the Arduino IDE doesn't send anything to the serial port!!!

The code "debug()" is an LCD module connected to the board and "debug" simply sends the text to the LCD (since the serial port is in use for the ISP I needed a different way to watch what's going on).

If I start up a stand-alone serial terminal and type a letter, the debug message prints on the LCD, so I know the serial port is up and working and seeing data.

So the problem must be in the IDE - not talking to the serial port if the MEGA2560 board is selected!

Anyone have any idea why this is, and what can be done about it?

Thanks.......

-- Roger

2

Can you clarify something? You have two boards, right? The programming board and the target board.

Which is which in this scenario? You have a Uno hooked up via the USB, and then a Mega connected to the Uno (via the ICSP ports), and you try to upload? Is that it?

3

The basic problem is that if a MEGA2560 board is connected and "Burn Bootloader" is clicked, nothing is sent out by the IDE. It's got nothing to do with SPI, ICSP or anything else.

But, to answer your question: I have the Sparkfun ISP shield:

600×600 141 KB

This board connects to the UNO pins 13,12,11 and 10 and routes them to either the ZIF socket or the ICSP headers.

Plugging this board into an UNO and using the "Arduino as ISP" sketch with either the hardware SPI or a bit-bang SPI works equally well. The target device is either another UNO or a MEGA2560, connected via a 6 pin ribbon cable.

Now, what I wanted to do is plug that Sparkfun shield into a MEGA2560. Of course, HARDWARE SPI will not work because of the different pinout, but I thought that bit-banging the UNO SPI pins (13, 12, 11 and 10) would allow it to work.

But it doesn't work, and the reason is doesn't work is that the Arduino IDE does not send anything to the comm port when "Burn Bootloader" is clicked. It's not an SPI problem.

Now, let me make sure this is clear: I can take an UNO board and write a simple sketch like this (pseudo-code):

Serial.begin(19200);
init the lcd();
loop() {
    if (Serial.available()) {
        x = Serial.read();
        print x to the LCD display
    }
}

...and if I then click "Burn Bootloader" zillions of characters are received by the serial port and displayed on the LCD (gibberish of course, but it proves to me that the serial comm is talking).

Now take that same code and move it to a MEGA2560. Click "Burn Bootloader". NOTHING HAPPENS!

To verify it's working, I can open a terminal program and type some letters. They show up on the LCD display.

So you see, it's not an SPI problem or anything else... it's the fact that the IDE does not send anything out when "Burn Bootloader" is clicked and a MEGA is connected.

I hope all this made sense, because it's making me dizzy! :slight_smile:

(edit to add): Is there any difference in the reset circuits between the UNO and the MEGA2560? I kinda have the feeling that the IDE is waiting for the MEGA to do something before it will start talking and the MEGA isn't responding properly.

4

Now take that same code and move it to a MEGA2560. Click "Burn Bootloader". NOTHING HAPPENS!

Oddly enough, I don't think you answered my question.

You don't move code to a Mega2560.

Are you targetting a Mega? Or are you using the Mega as an ISP?

Perhaps a simple drawing, showing what is connected to what.

5

OK let me try again. "Move" code was a poor choice of words.

First of all, please forget ISP altogether for now.

Setup #1: Arduino UNO R3 with LCD display attached and sketch compiled and loaded that reads the serial port at 19200 baud and sends received chars to the LCD.

Setup #2: Arduino MEGA 2560 R3 with LCD display attached and sketch compiled and loaded that reads the serial port at 19200 baud and sends received chars to the LCD.

Note: The sketch is exactly the same. it's simply compiled for UNO and uploaded to UNO, or compiled for MEGA and uploaded to MEGA.

Results #1 (UNO): When I click on "Burn Bootloader" in the IDE, some characters are received by the UNO and displayed on the LCD

Results #2 (MEGA): When I click on "Burn Bootloader" in the IDE, absolutely nothing happens. NO serial data is received.

Lastly, to verify that the sketch actually works on both boards, if I instead fire up a serial terminal emulator and type letters, they show up on the LCD on both the UNO and MEGA, so I know the code is running and working.

The bottom line of my problem is that if a MEGA2560 R3 board is connected to the IDE, and then "Burn Bootloader" is clicked, nothing is sent.

I hope this explained the problem more clearly. If not let me know and I'll try again! :slight_smile:

6

Krupski:
Results #2 (MEGA): When I click on "Burn Bootloader" in the IDE, absolutely nothing happens. NO serial data is received.

I wonder what serial port settings the "Burn Bootloader" command assumes. Maybe they don't match what you're using in your sketch?

7

The burn bootloader process works only by first selecting what kind of programmer you are going to use to burn the bootloader via ISP to a specific board type. If you wish to use an arduino board as a ISP programmer you first have to load if with the arduinoISP sketch, then select arduinoISP as the hardware programmer type, then select the type of board you wish to burn a bootloader to. Only then are you ready to select the burn bootloader command.

Lefty

8

retrolefty:
The burn bootloader process works only by first selecting what kind of programmer you are going to use to burn the bootloader via ISP to a specific board type. If you wish to use an arduino board as a ISP programmer you first have to load if with the arduinoISP sketch, then select arduinoISP as the hardware programmer type, then select the type of board you wish to burn a bootloader to. Only then are you ready to select the burn bootloader command.

Lefty

Yes I know that. Of course I selected "Arduino as ISP". The problem is that the IDE sends data to an UNO, but it doesn't send data to a MEGA.

And as I said, this isn't an "ISP" problem because the IDE simply will not send serial data to a MEGA, but it will send data to an UNO.

It's not a baud rate problem because in my test sketch I tried every baud rate from 1200 to 115200 and none of them work if a MEGA is plugged in.

Also, the "Serial.available()" call will trigger even if the baud rate is wrong. The data is corrupt of course because of the baud rate mismatch, but it does detect that SOMETHING is there.

The problem is solely that the IDE will not send "Burn Bootloader" data if it's connected to a MEGA 2560 R3 board.

9

PeterH:

Krupski:
Results #2 (MEGA): When I click on "Burn Bootloader" in the IDE, absolutely nothing happens. NO serial data is received.

I wonder what serial port settings the "Burn Bootloader" command assumes. Maybe they don't match what you're using in your sketch?

I thought of that and tried all baud rates from 1200 to 115200. None worked (with the MEGA). Of course, 19200 works with the UNO.

10

Krupski:
The problem is solely that the IDE will not send "Burn Bootloader" data if it's connected to a MEGA 2560 R3 board.

Why do you spell 'symptom' as p-r-o-b-l-e-m?

11

The problem is solely that the IDE will not send "Burn Bootloader" data if it's connected to a MEGA 2560 R3 board.

And what sketch is loaded onto the mega board when you press the burn bootloader button? You talked about a sketch that talks to a lcd display at 19200 baud rate as setup #1 and #2 sketch, but burn bootloader only works with an attached arduino board if the board is actively running only the arduinoISP sketch. So at best your symptom description is very confusing.

Lefty

12

retrolefty:
And what sketch is loaded onto the mega board when you press the burn bootloader button? You talked about a sketch that talks to a lcd display at 19200 baud rate as setup #1 and #2 sketch, but burn bootloader only works with an attached arduino board if the board is actively running only the arduinoISP sketch. So at best your symptom description is very confusing.
Lefty

I can't believe this is so confusing!

When the IDE is setup to use "Arduino as ISP", when you click "Burn Bootloader", the IDE sends various command bytes at 19200 baud to the serial port.

NORMALLY these commands are grabbed by the "Arduino as ISP" sketch and sent to the SPI pins in order to program a connected AVR chip.

But, this serial data should be able to be "seen" by ANY sketch that listens to the serial port.

Now, If I open a serial port at 19200 baud and "listen" to it, then clicking "Burn Bootloader" should send me the various command bytes that are used to program the AVR chip.

OK? So far so good?

If I take an Arduino UNO, write a tiny sketch that listens to the serial port and echos the data to an LCD display and then click "Burn Bootloader", I see some of the command bytes that the IDE sends out (trying, in vain of course, to kick an AVR chip into program mode).

Now, take the same sketch, compile and upload it to a MEGA instead, then click "Burn Bootloader" - NO SERIAL DATA IS RECEIVED.

None of this has to do with the supplied "Arduino as ISP" sketch. It's simply a matter of expecting to see data at the serial port and having success with an UNO, but failure with a MEGA.

I just don't know how to make it any more clear than this.

13

I just don't know how to make it any more clear than this.

I guess what is confusing is that you are possibly the very first person in all of arduino history to try and do such a thing. So while I can't solve your problem I would ask one more.

If you do load your mega board with the arduinoISP sketch does it function OK as a ISP programmer to a target chip or board?

I've used the arduinoISP programmer frequenctly but only running on 328P based boards, not on mega based boards. However I have burned bootloaders onto mega boards that way.

Lefty

14

Krupski:
I can't believe this is so confusing!

Me neither. :slight_smile:

Now, If I open a serial port at 19200 baud and "listen" to it, then clicking "Burn Bootloader" should send me the various command bytes that are used to program the AVR chip.

Oddly enough, I can reproduce this. It might have been simpler to post your "tiny sketch" rather than all this stuff about your "own" Arduino as ISP, with LCD screens etc. which makes one wonder if you have done something strange. But, no matter.

With this test sketch:

const byte LEDin = 6;
const byte LEDout = 7;

void setup ()
  {
  Serial.begin (19200);
  pinMode (LEDin, OUTPUT);
  digitalWrite (LEDin, LOW);
  pinMode (LEDout, OUTPUT);
  digitalWrite (LEDout, LOW);
  }  // end of setup

void loop ()
  {
  if (Serial.available ())
    {
    digitalWrite (LEDin, HIGH);
    byte c = Serial.read ();
    digitalWrite (LEDin, LOW);

    digitalWrite (LEDout, HIGH);
    Serial.write (c);  
    digitalWrite (LEDout, LOW);
    }
  }  // end of loop

That should read from Serial, and write whatever it gets back out. Plus some debugging LED flashes.

Results:

The 3 blips with a red box around are the '0' bytes sent by avrdude, like this:

avrdude: Version 5.11, compiled on Sep  2 2011 at 18:52:52
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/Applications/Arduino_1.0.3.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/Users/nick/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/cu.usbmodemfa131
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

avrdude done.  Thank you.

The one on the left and one on the right are 0xFF.

So you appear to be right. The Mega is behaving very strangely. It gets the data, because the "LEDin" LED goes high. However after that it just seems to hang. Although LEDout goes high as well. However LEDin doesn't go low. Nor does anything get sent.

LEDin is high for 6.6 seconds!

If I load the ASCII map (example) onto the same board, it works:

ASCII Table ~ Character Map
!, dec: 33, hex: 21, oct: 41, bin: 100001
", dec: 34, hex: 22, oct: 42, bin: 100010
#, dec: 35, hex: 23, oct: 43, bin: 100011
$, dec: 36, hex: 24, oct: 44, bin: 100100
%, dec: 37, hex: 25, oct: 45, bin: 100101
&, dec: 38, hex: 26, oct: 46, bin: 100110
', dec: 39, hex: 27, oct: 47, bin: 100111
(, dec: 40, hex: 28, oct: 50, bin: 101000
), dec: 41, hex: 29, oct: 51, bin: 101001
*, dec: 42, hex: 2A, oct: 52, bin: 101010
+, dec: 43, hex: 2B, oct: 53, bin: 101011
,, dec: 44, hex: 2C, oct: 54, bin: 101100
-, dec: 45, hex: 2D, oct: 55, bin: 101101
., dec: 46, hex: 2E, oct: 56, bin: 101110
/, dec: 47, hex: 2F, oct: 57, bin: 101111
0, dec: 48, hex: 30, oct: 60, bin: 110000
1, dec: 49, hex: 31, oct: 61, bin: 110001
2, dec: 50, hex: 32, oct: 62, bin: 110010
3, dec: 51, hex: 33, oct: 63, bin: 110011
4, dec: 52, hex: 34, oct: 64, bin: 110100
5, dec: 53, hex: 35, oct: 65, bin: 110101
6, dec: 54, hex: 36, oct: 66, bin: 110110
7, dec: 55, hex: 37, oct: 67, bin: 110111
8, dec: 56, hex: 38, oct: 70, bin: 111000
9, dec: 57, hex: 39, oct: 71, bin: 111001
:, dec: 58, hex: 3A, oct: 72, bin: 111010
;, dec: 59, hex: 3B, oct: 73, bin: 111011
<, dec: 60, hex: 3C, oct: 74, bin: 111100
=, dec: 61, hex: 3D, oct: 75, bin: 111101
>, dec: 62, hex: 3E, oct: 76, bin: 111110
?, dec: 63, hex: 3F, oct: 77, bin: 111111
@, dec: 64, hex: 40, oct: 100, bin: 1000000
A, dec: 65, hex: 41, oct: 101, bin: 1000001
B, dec: 66, hex: 42, oct: 102, bin: 1000010
C, dec: 67, hex: 43, oct: 103, bin: 1000011
D, dec: 68, hex: 44, oct: 104, bin: 1000100
E, dec: 69, hex: 45, oct: 105, bin: 1000101
F, dec: 70, hex: 46, oct: 106, bin: 1000110
G, dec: 71, hex: 47, oct: 107, bin: 1000111
H, dec: 72, hex: 48, oct: 110, bin: 1001000
I, dec: 73, hex: 49, oct: 111, bin: 1001001
J, dec: 74, hex: 4A, oct: 112, bin: 1001010
K, dec: 75, hex: 4B, oct: 113, bin: 1001011
L, dec: 76, hex: 4C, oct: 114, bin: 1001100
M, dec: 77, hex: 4D, oct: 115, bin: 1001101
N, dec: 78, hex: 4E, oct: 116, bin: 1001110
O, dec: 79, hex: 4F, oct: 117, bin: 1001111
P, dec: 80, hex: 50, oct: 120, bin: 1010000
Q, dec: 81, hex: 51, oct: 121, bin: 1010001
R, dec: 82, hex: 52, oct: 122, bin: 1010010
S, dec: 83, hex: 53, oct: 123, bin: 1010011
T, dec: 84, hex: 54, oct: 124, bin: 1010100
U, dec: 85, hex: 55, oct: 125, bin: 1010101
V, dec: 86, hex: 56, oct: 126, bin: 1010110
W, dec: 87, hex: 57, oct: 127, bin: 1010111
X, dec: 88, hex: 58, oct: 130, bin: 1011000
Y, dec: 89, hex: 59, oct: 131, bin: 1011001
Z, dec: 90, hex: 5A, oct: 132, bin: 1011010
[, dec: 91, hex: 5B, oct: 133, bin: 1011011
\, dec: 92, hex: 5C, oct: 134, bin: 1011100
], dec: 93, hex: 5D, oct: 135, bin: 1011101
^, dec: 94, hex: 5E, oct: 136, bin: 1011110
_, dec: 95, hex: 5F, oct: 137, bin: 1011111
`, dec: 96, hex: 60, oct: 140, bin: 1100000
a, dec: 97, hex: 61, oct: 141, bin: 1100001
b, dec: 98, hex: 62, oct: 142, bin: 1100010
c, dec: 99, hex: 63, oct: 143, bin: 1100011
d, dec: 100, hex: 64, oct: 144, bin: 1100100
e, dec: 101, hex: 65, oct: 145, bin: 1100101
f, dec: 102, hex: 66, oct: 146, bin: 1100110
g, dec: 103, hex: 67, oct: 147, bin: 1100111
h, dec: 104, hex: 68, oct: 150, bin: 1101000
i, dec: 105, hex: 69, oct: 151, bin: 1101001
j, dec: 106, hex: 6A, oct: 152, bin: 1101010
k, dec: 107, hex: 6B, oct: 153, bin: 1101011
l, dec: 108, hex: 6C, oct: 154, bin: 1101100
m, dec: 109, hex: 6D, oct: 155, bin: 1101101
n, dec: 110, hex: 6E, oct: 156, bin: 1101110
o, dec: 111, hex: 6F, oct: 157, bin: 1101111
p, dec: 112, hex: 70, oct: 160, bin: 1110000
q, dec: 113, hex: 71, oct: 161, bin: 1110001
r, dec: 114, hex: 72, oct: 162, bin: 1110010
s, dec: 115, hex: 73, oct: 163, bin: 1110011
t, dec: 116, hex: 74, oct: 164, bin: 1110100
u, dec: 117, hex: 75, oct: 165, bin: 1110101
v, dec: 118, hex: 76, oct: 166, bin: 1110110
w, dec: 119, hex: 77, oct: 167, bin: 1110111
x, dec: 120, hex: 78, oct: 170, bin: 1111000
y, dec: 121, hex: 79, oct: 171, bin: 1111001
z, dec: 122, hex: 7A, oct: 172, bin: 1111010
{, dec: 123, hex: 7B, oct: 173, bin: 1111011
|, dec: 124, hex: 7C, oct: 174, bin: 1111100
}, dec: 125, hex: 7D, oct: 175, bin: 1111101
~, dec: 126, hex: 7E, oct: 176, bin: 1111110

Using the above test sketch (with the LEDs) and simply typing "abcdef" into the serial monitor, it works as expected:

I don't know what to make of this, except that maybe the Serial monitor initializes the USB chip (eg. by sending RTS low) and that avrdude doesn't. I can't think of any other explanation. And even that doesn't explain why LEDin stays high for so long.

15

Well, I worked it out, lol.

I made one tiny change, one bit, and now everything works.

avrdude: Version 5.11, compiled on Sep  2 2011 at 18:52:52
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/Applications/Arduino_1.0.3.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/Users/nick/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/cu.usbmodemfa131
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [10] 
         AVR Part                      : ATMEGA2560
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    10     8    0 no       4096    8      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           flash         65    10   256    0 yes    262144  256   1024  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
avrdude: Send: A [41] . [80]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [02] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [81]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [01] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [82]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [12] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [98]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
avrdude: Send: A [41] . [84]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [85]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [86]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [87]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [89]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: Send: A [41] . [81]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [01] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [82]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [12] 
avrdude: Recv: . [10] 
avrdude: Send: B [42] . [00] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [00] . [00] . [00] . [00] . [01] . [00] . [10] . [00] . [00] . [04] . [00] . [00]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [10] 
avrdude: Send: E [45] . [05] . [08] . [d7] . [a0] . [00]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [10] 
avrdude: Send: P [50]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

It failed at the end because I didn't have anything plugged into the Mega.

And the test program above works now:

Whoops, have to go! See if you can guess what the one-bit change was. :slight_smile:

16

The problem was the bootloader. The Mega bootloader also listens to the serial port, so it "absorbed" the bytes from avrdude.

To work around it I cleared the BOOTRST fuse, so it booted straight into the sketch and not the bootloader (set the high fuse from 0xD8 to 0xD9).

That explains why in my test sketch the LEDs did not respond in the way I expected, and why nothing was echoed.

For a longer term solution:

  • Find a bootloader that doesn't do that.
  • Change the fuse after uploading your sketch, and change it back when you need to upload a new one.
  • Change the fuse, and then upload sketches via ICSP (thus not requiring a bootloader).

It's kind of annoying having a bootloader that sits there waiting for "commands" like that. I don't know personally where to get a version that doesn't do it.

17

Isn't there a conventional hardware mod to prevent the Arduino from being reset by the serial port when it is being used as an ISP programmer? I've never done it myself but seem to remember reading something of the sort.

18

10(?) uF cap between reset and ground?

19

Yes, good point, I'd forgotten about that.

Adding a 33 uF (the exact size wouldn't be important) between reset and Gnd fixed the issue. Basically it stops the board resetting, and thus it doesn't drop into the bootloader. Now we know why we do that. :slight_smile:

So you would have to pull the cap out to upload a new version of the Arduino as ISP sketch, and put it in to program a target board.

20

The funny thing is I own a 'real' Duemilanove 328P board and have been playing with the arduinoISP sketch for a month or two now (along with a USBtiny and USBasp hardware programmers) and I have never ever had to defeat the auto reset via a resistor or cap to burn a bootloader or upload using programmer.

So that is still a mystery of why sometimes or some boards need it but others don't? My steps are I wire the target to the Duemilanove board, then upload the arduinoISP sketch and then either use burn bootloader or upload using programmer action, and I've never had a failure with out having to try and defeat auto-reset.

Lefty