Added the capacitor, same connection as shown on the photos. Now the upload takes ages (couple of minutes) then the following error log shows up:
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x03
Problem beim Hochladen auf das Board. Hilfestellung dazu unter http://www.arduino.cc/en/Guide/Troubleshooting#upload.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x03
IDE Settings:
Board: "Arduino Nano"
Programmer: "Arduino as ISP"
I really don't know what's wrong here. Guess I'll have to live with the 2.5 sec startup delay then
I've not looked at this in quite some time but in the past it was incorrect when using the "upload with programmer" option.
I reported this MANY years ago. I'm guessing that the IDE is still miscalculating it - it pretty much has to still have this issue given the limitation in information it has available from the boards.txt file.
The issue is that the boards.txt file doesn't contain enough information to calculate the space depending on if a bootloader is installed/used - which it isn't - when you burn the sketch code with a programmer vs using the bootloader.
The IDE used upload.maximum_size as the memory size from the board.txt entry from the boards.txt entry which does not properly reflect total available flash when using the upload with programmer option.
What they needed in the boards.txt entry is total flash size and bootloader size.
Then they could do the math properly to figure out the maximum space available for uploading depending on whether a bootloader was installed and being used.
The only way to "trick" the IDE into use that bootloader space is to create a new board entry for the board that specifies the full size of the flash but then you have to do something in the entry to disable using a bootloader to ensure that the user doesn't attempt to burn a full sized application that won't fit when the bootloader is installed.
hmmm. The bootloader was fix many years ago to start the application directly on powerup. - even before optiboot existed.
This must be a REALLY old bootloader.
I'm wondering if you have a potential issue related to flash size.
i.e. this bootloader may be one of the REALLY old bootloaders that is 1k vs the more recent ones all being 512 bytes.
If so then your boards.txt entries are all incorrect since they are set to indicate that the bootloader is only 512 bytes.
You can check this by looking at the fuses.
You can also look at the on board led during powerup vs pushing the reset.
The newer bootloaders will jump to the application without flashing the LDE.
It will blink the LED as the bootloader starts up and begins looking for an upload.
i.e the LED should blink with you press reset but not when it powers up.
I'd just burn a new bootloader.
You can then know for sure what you have and the size will match what is expected in the boards.txt file entries.
The IDE has the capability to do this and even comes with the bootloader.
If you have an ISCP programmer, just use the IDE to burn a new bootloader and enjoy the faster powerup startup times.
The wiring looks right to me. And you have the capacitor installed. I would suspect the jumpers or the breadboard - a connection issue of some kind.
I just tested one of my Nano clones which has the old bootloader, and indeed it does have a delay of a little over a second on powerup even if powered directly at the 5V pin, with no USB connected. It flashes the D13 LED briefly, then takes about a second to begin executing the sketch. You can see that with Blink. I don't know about more recent bootloaders. In any case, flashing with the programmer should work.
Let's try this is two stages. Instead of saying the target board is an "Arduino Nano", claim it is an "Arduino Uno". Then, instead of attempting to load a sketch onto it, simply use the "Burn Bootloader" option. This should load the opti-bootloader onto the target "Nano". From now on, if that succeeds, you must treat that target "Nano" as if it were a Uno. That is, if you want to download a sketch to it, you must select the board "Arduino Uno".
Incidentally, I do this with all my Nanos so these are effectively "Unos" with a small and quick bootloader.
EDIT
There is a further advantage to this. The "old" Nano bootloader had a bug which made it incompatible with the watch dog timer, forcing it, under certain circumstances, into an endless reset cycle.
IIRC, the changes were made in the source, but not in the .hex files for various boards.
See: Incorporating ladyada's watchdog timer changes into the bootloader so… · arduino/ArduinoCore-avr@080d18c · GitHub
It looks like the mods are still not in any of the m328 bootloader .hex files in the Arduino distribution, although I think both Adafruit and Sparkfun were shipping boards with the modified bootloader since way back. The Makefile does not contain an entry that builds a m328 bootloader with the WATCHDOG_MODS setting.
is the bootloader actually removed by the process of uploading using ICSP
The bootloader is actually removed (erased), but the restart vector is not changed. So the board will initially jump to the old bootloader start address, where it will execute 2k worth of erased flash (which are approximately no-ops), until the program counter loops around to the actual sketch start at 0x0.
(Minicore with the "no bootloader" option will fix this when you do a "burn bootloader" (which is really "set fuses" in this case), but I don't think it will change fuses on "upload using programmer. (it would be "dangerous" for "upload" to start changing fuses, perhaps.))
What I meant was @2KBastler could update his nano boards with the optiboot bootloader that comes with the ide.
Nothing odd or special needed other than an ISP programmer.
Just use "burn bootloader" and you get the optiboot bootloader on the boards I mentioned.
I thought you were implying that there was not a "no wait" bootloader that came with the IDE when you said:
I think I have to apologise for all your patience guys, because after re-checking every single connection, it turned out that the capacitor pins had no contact to the worn out breadboard (the legs are just so thin). After fiddling around a bit everything worked as you explained above. Thanks a lot!!!!!
Now the leds on both boards are flashing while the sketch is uploading - before, only the red led was lit up constantly.
The target board now starts up instantly, there is no noticable boot time anymore.
So, as a conclusion, the most important part was to add a capacitor between the GND and the RST pin of the programmer. I used a 100mF since I could not find a smaller one and it worked.
That's interesting about the capacitor. I've always needed it, but I'm still running IDE v1.8.8. I've been told that newer versions made changes so the capacitor is no longer needed. But obviously whatever version 2KBastler is running still requires it. Does anyone know the version where the change was made so the capacitor is no longer needed?
Also, my understanding is that burning it as an Uno rather than burning the "new" Nano bootloader, is that while the new Nano bootloader is 512 bytes, the memory assigned to the bootloader is still 2K. This was an outright error when Arduino went to the new Nano bootloader, but by the time anyone noticed, it was too late to change it. So turning it into an Uno is how you save the 1.5K. Can anyone confirm this?
The BareMinimum sketch compiled for a Nano classic
Old Bootloader
Sketch uses 444 bytes (1%) of program storage space. Maximum is 30720 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.
New Bootloader
Sketch uses 444 bytes (1%) of program storage space. Maximum is 30720 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.
Uno Bootloader
Sketch uses 444 bytes (1%) of program storage space. Maximum is 32256 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.
This is essentially correct. The actual bootloader code is identical for the UNO and the "new" nano, only the fuse settings for bootloader memory allocation differ.
