Can't upload a sketch from the IDE to my bare-bone Arduino Nano

Hi all

I designed a bare-bone Arduino Nano which only has what I need for my project.
I was able to burn a bootloader to it and also, when connected to the PC, it is recognized as a COM port. But when I try to upload a sketch, I get the famous "stk500_getsync() not in sync resp=0x00" message.
I doubled checked my design and soldering and all is fine.

After hours of fiddling with it, I decided to try to avrdude command line options. What finally worked was to change the 57200 default baud rate used by the IDE to 115200! After that change, I had no problems uploading a sketch.

Any ideas why I had to change the baud rate? I am using the same FT232RL and ATMEGA328P-AU that are used in the original design. I did not buy them from Mouser or a "normal" supplier, I got them from some seller on eBay from almost half the price.

Is the baud rate settings used by avrdude are for the PC-FTDI chip communication or the FTDI-ATMEGA chip communication?

Hi,

szangvil:
Any ideas why I had to change the baud rate?

Because the bootloader, fuse settings, and crystal (or resonator) establish that the baud rate has to be 115200.

Is the baud rate settings used by avrdude are for the PC-FTDI chip communication...

No. The PC and FTDI chip communicate via USB at a USB bitrate: 1.5, 12, or 480 Mbit/s (probably 12).

...or the FTDI-ATMEGA chip communication?

Yes.

I used the same resonator as on the original Nano... I tried to burn all possible 328 16MHz bootloaders to a standard Nano, and there were no issues to upload at 57600. I did the same to my bare bone Nano and I could only upload at 115200, regardless of the bootloader used.

Which boooader did you burn to the MCU and via what method?

The bootloader has a baud rate it expects communication on, and this is complemented by the same rate set in boards.txt so the IDE knows what baud rate to use when invoking avrdude.

If you use Arduino as ISP to burn the bootloader then you normally do it with a target board selected and hence the correct bootloader and boards.txt entry are in sync.

If you used a different method to burn a bootloader file directly then maybe the bootloader and boards.txt entry don't reflect each other?

I used an Uno as my programmer and followed these instructions to burn the bootloader:

The steps to burn the bootloader:

  1. Open the ArduinoISP firmware (in Examples) to your Arduino board.
    Note for Arduino 1.0: you need to make one small change to the ArduinoISP code. Find the line in the heartbeat() function that says “delay(40);” and change it to “delay(20);”.

  2. Select the items in the Tools > Board and Serial Port menus that correspond to the board you are using as the programmer (not the board being programmed).

  3. Upload the ArduinoISP sketch

  4. Wire your Arduino board to the target as shown in the diagram below.

  5. Select the item in the Tools > Board menu that corresponds to the board on which you want to burn the bootloader (not the board that you’re using as the programmer). See the board descriptions on the environment page for details.

6.Use the Burn Bootloader > Arduino as ISP command.

The strange thing is, if I do the EXACT same thing with a "standard nano" and with my "bare bone nano", I get different behaviours... to the standard nano I can upload a sketch from the IDE (at 57600) and to my bare bone nano, I can not - only via command line setting the avrdude baud rate to 115200.

The standard Nano you have is using the Duemilanove bootloader, which works at 57600. Even though it's a different form factor, you program it by picking "Duemilanove" from the board type menu.

The Uno uses OptiBoot for its bootloader, which works at 115200 baud. It's the new standard because it's smaller (512 bytes vs about 2K). When you burned your new standalone chip you got OptiBoot.

So, if you treat your new Nano clone as a Uno, everything should work fine.

Good luck!

magagna:
The standard Nano you have is using the Duemilanove bootloader, which works at 57600. Even though it's a different form factor, you program it by picking "Duemilanove" from the board type menu.

The Uno uses OptiBoot for its bootloader, which works at 115200 baud. It's the new standard because it's smaller (512 bytes vs about 2K). When you burned your new standalone chip you got OptiBoot.

So, if you treat your new Nano clone as a Uno, everything should work fine.

Good luck!

Yes he somehow loaded the Uno's bootloader onto his standalone nano setup. That will work if he selects the Uno as the board selection prior to performing a IDE serial upload.

However he will lose I believe the ability to use the extra 2 analog input pins that the nano's version of the SMD 328p chip has. If he wants those back be has to edit the nano/328 entry in the core's boards.txt file to reflect having the Uno's bootloader name, path, baud rate, fuse bytes, memory size, etc.

Lefty

However he will lose I believe the ability to use the extra 2 analog input pins that the nano's version of the SMD 328p chip has. If he wants those back be has to edit the nano/328 entry in the core's boards.txt file to reflect having the Uno's bootloader name, path, baud rate, fuse bytes, memory size, etc.

No need for anything like that. A6 & A7 are defined in pins_arduino.h, which is common for all "standard" board entries.

magagna:

However he will lose I believe the ability to use the extra 2 analog input pins that the nano's version of the SMD 328p chip has. If he wants those back be has to edit the nano/328 entry in the core's boards.txt file to reflect having the Uno's bootloader name, path, baud rate, fuse bytes, memory size, etc.

No need for anything like that. A6 & A7 are defined in pins_arduino.h, which is common for all "standard" board entries.

If that is true why does the core's board.txt have an entry for just some boards but not for instance the Uno board?

#nano328.build.variant=eightanaloginputs

Lefty

Defining the board as Uno does the trick and lets me upload the sketch.
What I don't understand is that I BURNED the SAME bootloader to both Nanos (mine and the standard). And to the standard, there was no problem and it acted "normally" where mine does not.

szangvil:
Defining the board as Uno does the trick and lets me upload the sketch.
What I don't understand is that I BURNED the SAME bootloader to both Nanos (mine and the standard). And to the standard, there was no problem and it acted "normally" where mine does not.

The fact remains that somehow you didn't load the SAME bootloader, as the baud rate used by a specific bootloader is part of the internal code in the bootloader, the same bootloader could not possibly work at two different baud rates.

Lefty

Defining the board as Uno does the trick and lets me upload the sketch.
What I don't understand is that I BURNED the SAME bootloader to both Nanos (mine and the standard). And to the standard, there was no problem and it acted "normally" where mine does not.

Glad you got it working. I'm not sure why there would be a difference if you burned the same bootloader on both boards...unless maybe the burn of the real Nano didn't work so it still has the original Duemilanove bootloader? I can tell you that I've successfully reflashed my Nano 3.0 with OptiBoot and it works fine when I upload sketches to it using "Uno" as the selected board type.

If that is true why does the core's board.txt have an entry for just some boards but not for instance the Uno board?
#nano328.build.variant=eightanaloginputs

I'm not one of the original Arduino development coders so I can't speak to why they wrote it that way.

What I can say is that all eightanaloginputs/pins_arduino.h does is include standard/pins_arduino.h but redefines NUM_ANALOG_INPUTS to be 8 instead of 6.

The only place NUM_ANALOG_INPUTS is used is in in boards.h where it sets TOTAL_ANALOG_PINS, and the only place that's used is in IS_PIN_ANALOG(), which doesn't appear to be used anywhere.

As far as I'm aware the only place where the number of analog pins would be relevant is in analogRead(), and the only thing analogRead() cares about is if you're sending it 0-7 (the analog pins by themselves) or 14-21 (the analog pins' digital pin equivalences).

In any event, this code compiles & uploads fine when the board type is set to "Uno":

void setup(void) {
    Serial.begin(9600);
    }

void loop(void) {
   Serial.println(analogRead(7));
   delay(250);
   }

but of course it won't actually do anything unless you're using an ATMega328 with A6 & A7.

The code didn't work on my board. im having the same problem.

424crash:
The code didn't work on my board. im having the same problem.

@szangvil reported that everything does work. How could you be having the same problem?

424crash:
The code didn't work on my board. im having the same problem.

That's not enough information for us to help you.

What code? My sample of using A6/A7 on a Uno? Retrolefty's editing of boards.txt? Uploading OptiBoot to a preassembled Nano? Uploading a bootloader to a homemade Nano clone?

What problem? stk500 errors? The PC recognizing the Arduino? Baud rates? Board types?