[SOLVED?]Anyone Here Using VisualStudio Code for Arduino With a Nano?

I've been using VisualStudio Code for several months, and mostly really like it. But, yesterday I created a new project, and for some reason I cannot get it configured correctly. I get the following two errors:

#include errors detected. Please update your includePath. Squiggles are disabled for this translation unit (E:\Users\RayL\Documents\Arduino\StepperGauge\StepperGauge.ino).

cannot open source file "avr/pgmspace.h" (dependency of "E:\Users\RayL\Documents\Arduino\StepperGauge\StepperGauge.ino")

But my c_cpp_properties.json and arduino.json are essentially identical to the ones in several working projects created some time ago, except for the project/sketch name!

The sketch itself is fine, and compiles and runs correctly if I use the Arduino IDE. So, I have to wonder if the problem has to do with the fact that this project is using a Nano, instead of the micros, Megas, etc. I've used for other projects.

Anyone know enough about VSCode configuration to have a clue what might be going on?

Regards,
Ray L.

Ray:

I’m sure you checked your Path setting. I just used DuckDuckGo to look for “vs code c++ extension includepath” and there is some info that might be helpful.

econjack:
Ray:

I'm sure you checked your Path setting. I just used DuckDuckGo to look for "vs code c++ extension includepath" and there is some info that might be helpful.

I have discovered the code is, in fact, compiling without error, and a HEX file is created. The problem appears to be in the upload. For some reason, it is unable to sync to the Nano, so appears to hang (with no output to the console unless verbose is turned on). It eventually gives up and returns after 10 attempts at syncing.

Today I will use verbose on a Mega project to compare the avrdude command line options. There must be something missing or wrong on the command line when a Nano is used. Seems odd though, since it works fine using the Arduino IDE, and they should both be using the IDE build process.

I've grown rather fond of VSCode. I find it more convenient than full VisualStudio, and much lighter-weight. Clearly less functionality, but few things that I really miss. My only major complaint is the SerialMonitor functionality is awful - actually crashed my PC several times! I now just use PuTTY instead.

Regards,
Ray L.

I can't help with Visual Studio as I use Eclipse (Sloeber). However, if you have a problem specifically with a Nano, one solution may be to load the Opti bootloader onto the Nano and then simply treat it in the same way as you would a Uno. I do that with all my Nanos.

The nano can come with either of two bootloaders. In the arduino IDE there is an option for "old bootloader" that is often needed to get it to upload, not sure how to specify that with your software.

As the previous post mentions, you can also put the uno bootloader on a nano, then compile for an uno.

david_2018:
The nano can come with either of two bootloaders. In the arduino IDE there is an option for “old bootloader” that is often needed to get it to upload, not sure how to specify that with your software.

As the previous post mentions, you can also put the uno bootloader on a nano, then compile for an uno.

Selecting the “Old bootloader” often solves the Upload issue with a lot of Arduino clones that use the CH340 driver, too.

I have re-FLASHed the boot loader in all of my Nanos, using the Arduino IDE and a USBTinyISP. So, the boot loader should not be the problem, I think. Besides, as I said, it all works fine with the IDE, only the upload using VSCode is failing.

Regards,
Ray L.

I feel inferior , just can’t get into Studio :frowning:.

Only use it for printing out sketches lol. - it’s great at that.

This is perplexing.... I see nothing wrong with the command lines. Here is the command VSCode creates:

E:\Users\RayL\Documents\AppData\Arduino\arduino-1.8.8\hardware\tools\avr/bin/avrdude 
 -CE:\Users\RayL\Documents\AppData\Arduino\arduino-1.8.8\hardware\tools\avr/etc/avrdude.conf 
 -v 
 -patmega328p 
 -carduino 
 -PCOM4 
 -b115200 
 -D 
 -Uflash:w:e:\Users\RayL\Documents\Arduino\Build/StepperGauge.ino.hex:i

Here is the command line the IDE creates:

E:\Users\RayL\Documents\AppData\Arduino\arduino-1.8.8\hardware\tools\avr/bin/avrdude
 -CE:\Users\RayL\Documents\AppData\Arduino\arduino-1.8.8\hardware\tools\avr/etc/avrdude.conf 
 -v 
 -patmega328p 
 -carduino 
 -PCOM4 
 -b115200 
 -D 
 -Uflash:w:C:\Users\RayL\AppData\Local\Temp\arduino_build_156912/StepperGauge.ino.hex:i

The only difference I see is the HEX file paths are different, because they are using different build directories. But both paths are valid, and the two HEX files are present, and identical.

I tried moving the build directory to C:\Users\RayL\AppData\Local\Temp, but it stills fails in the same way.

I'm confused....

Regards,
Ray L.

The only odd thing is that the drive letter is a capital 'E' in the path to avrdude and a lower case 'e' in the -U filename path.
Maybe under Windows, that is no problem but how did it happen ?

6v6gt:
The only odd thing is that the drive letter is a capital 'E' in the path to avrdude and a lower case 'e' in the -U filename path.
Maybe under Windows, that is no problem but how did it happen ?

Don't know, but generally in VSCode, paths come from one of several JSON configuration files, which are hand-edited. But I don't see and lower-case drive names there either. In any case, Windows does not care about case. It seems to be avrdude that is getting confused.

Regards,
Ray L.

I wonder if there is a problem with PATH setup? If I copy the avrdude command line the Arduino IDE uses, open a Command shell, cd to the IDEs build directory, then run that command line, it does NOT work. It gets sync errors, just like I see with VSCode. The command line is absolutely correct, so the problem has to be something about the environment - either PATH is wrong, or avrdude expects some environment variable(s) to be set to enable it to operate correctly.

Anyone have a clue WHAT might be missing?

Regards,
Ray L.

Found it! Baud rate! Change the baud rate in the avrdude command line to 57600, and it works correctly.

But how is this wrong? I changed the boards.txt entry for Nano:

nano.menu.cpu.atmega328.upload.speed=57600

And now I can upload from VSCode. But WHY is this change necessary? Why does 115200 not work?? Is it a bootloader issue? I re-programmed the bootloaders in all these boards using Tools->Burn Bootloader in the Arduino IDE, using a USBTinyISP.

I'm very confused right now, and would REALLY like to know why this is happening...

Regards,
Ray L.

That is the baud rate for the old bootloader. You must have installed the old bootloadert in error.

tf68:
That is the baud rate for the old bootloader. You must have installed the old bootloadert in error.

Well.... I installed whatever bootloader gets installed when you go to Tools->Burn Bootloader in the IDE. Where does THAT bootloader come from, and how can I make it install the latest one?

Regards,
Ray L.

OK, the problem appears to be a problem with the "new" bootloader in the v1.8.8 IDE. It simply does NOT work on the Nano. I can use the old bootloader, but only at 57600. I instead programmed the bootloader as an Uno (which, BTW, specifies the exact same HEX file....), and now it works properly at 115200!

I'm more confused than ever, but at least it is finally working correctly!

Regards,
Ray L.

I note one difference in the bootloader specs in boards.txt for Uno and Nano:

This is for Uno:
uno.bootloader.tool=avrdude
uno.bootloader.low_fuses=0xFF
uno.bootloader.high_fuses=0xDE
uno.bootloader.extended_fuses=0xFD
uno.bootloader.unlock_bits=0x3F
uno.bootloader.lock_bits=0x0F
uno.bootloader.file=optiboot/optiboot_atmega328.hex

This is for Nano with the "new" bootloader:
nano.menu.cpu.atmega328.bootloader.low_fuses=0xFF
nano.menu.cpu.atmega328.bootloader.high_fuses=0xDA
nano.menu.cpu.atmega328.bootloader.extended_fuses=0xFD
nano.menu.cpu.atmega328.bootloader.file=optiboot/optiboot_atmega328.hex

Note the "bootloader.high" settings are different, and the lock/unlock settings are present ONLY for the Uno.

If I'm reading it right, the one bit difference in the high_fuse setting changes the bootloader size, which could certainly be a problem (remember both Uno and Nano use the exact same bootloader HEX file). Am I reading that right? If so, isn't the v1.8.8 boards.txt "broken" for the Nano with "new" bootloader?

What are the lock/unlock settings that appear only for the Uno?

Regards,
Ray L.

Well I would edit the Boards file to correct the High fuse to match the Uno. Then be sure that you have selected Tools/Processor:"ATmega328P" and then do a Burn Booloader. If you select "ATmega328P (Old Bootloader)" that is what you will get. The lock bits are there earlier in the section.

The fuse setting for the new bootloader size is too large, apparently when the change was made from the old bootloader, the fuse setting was not updated to fit the actual space requirement of the new bootloader. That is one of the reasons people run the uno bootloader on the nano, it gives you more program space.

tf68:
Well I would edit the Boards file to correct the High fuse to match the Uno.

Exactly what I did... But how am I the first person to have this problem?

Regards,
Ray L.