Hello all
I have programmed a bunch of Arduino Nano units (CHR340) with no problems (thru USB).
I got a different unit (with FTDI) now. When I try to upload the sketch, everything goes identically, but it freezes when the flash memory is to be written. I use AVRDUDE.exe ver. 6.3. Last successfull OP is reading the flash, then it writes:
and then it freezes.
The unit is brand new so I don't expect the problem is in a bootloader. I communicate with the unit at 57600 bps so I assume there in the "old" bootloader in it.
Any help will be tremendously appreciated as I am so desperate.
Yes, I do.
avrdude.exe -Cavrdude.conf -pm328p -carduino "-PCOM25" -b57600 -D -v -Uflash:w:SpiderKeyer.ino.hex:i
see the attached file.
Using IDE provides no relief. Whatever settings I try it ends up in the same manner.
The same command line (except serial port} works fine with CH340G chinese clones.
Sometimes it happens that just a beginning of the flash is written:
Writing | | 0% 0.00savrdude.exe: stk500_recv(): programmer is not responding
Writing | ## | 4% 10.06savrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_recv(): programmer is not responding
So it looks that I am just balancing on a border of something. Would it be worth of trying to supply an external voltage to Nano (12V) during uploading the sketch?
In 2018, Arduino changed the bootloader used on the official Arduino Nano to one that is configured for upload at 115200 baud. The old bootloader was configured for 57600. The clone and derivative manufacturers have been slow to catch up to the change. So if you buy a new official Nano, it will always be 115200, but with the clones and derivative boards, it's a toss up which bootloader you're going to get.
I am aware of the existence of the two different bootloaders. This arduino is not the original one, but a "precise clone". Purchased recently. Speed 115200 bps is one of many things I have tried. When set, it fails much sooner:
avrdude.exe: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "avrdude.conf"
Using Port : COM25
Using Programmer : arduino
Overriding Baud Rate : 115200
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 1 of 10: not in sync: resp=0x25
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 2 of 10: not in sync: resp=0x25
So it even doesn't start the communication with the unit.
Interesting is, IMHO, that from time to time it happens that 4% percent of the Flash is programmed before it stops responding.
you will get a tremendous amount of detail about what's happening. Whether any of it makes any sense is another matter! But perhaps it will provide a useful clue.
Done, file attached.
So far I tend to think the problem is in the unit, and it is an unexpected HW problem. Otherwise, I assume, the bootloader would return an error, something like "can't write to flash memory", rather than to freeze. On the other hand I don't think it is a harware failure of the unit. First, the unit is brand new. Second, all units of this kind (manufacturer) yielded the same problem.
I tried to supply an external voltage (12V) to the unit. It made no difference.
When IDE saves the compiled sketch it saves two versions of the file. One is marked "with bootloader". The very first thing I did with these troubled units was uploading this larger one. Does this overwrite the original bootloader? Could this possibly mess the things?
COM25 !
You might try one of those methods that gets rid of old COM ports ( Com Port creep - Arduino Yún - Arduino Forum )
(It shouldn't matter. But ... it could?) Worth an experiment?)
Thanks for the response.
As a programmer I know that it is sometimes necessary for 2-digit COMs to supply a magic prefix, like:
\.\COM25
for things to work. This, however, is not the case of avrdude.exe. After all at the beginning the communication goes on well. It is not the source of the problems.
In the meantime I used another healthy Nano to try to upload the bootloader:
I double checked the wiring but it failed either.
There is an interesting note in the article: some Nano clones are sold without a bootloader!
Finally, I realized that I own the programmer AVR ATAVRISP Mk II, I am trying now to upload the bootloader with it.
You wouldn't have gotten as far as you did with no bootloader, either.
It's pretty strange.
There have been assorted problems with "counterfeit" FTDI chips, mostly due to FTDI issuing new drivers that detect the counterfeits and refuse to work with them. (Search "FTDIgate") This could be a new installment of that...
Check which version of the FTDI driver windows has "automatically updated" for you...
(or you could have counterfeit FTDIs that simply don't work; out of spec on bitrate or something (which would tend to allow short negotiations but fail on large strings of data. maybe.))
I can find a chip on the board that is marked FT232, so I belive it is the original FTDI chip.
The properties of the driver in Device Manager look healthy, as FTDI, date of the drivers: 8/16/2017
Furthemore, the communication runs fine until the flash memory is to be written. Before this, the flash memory is read and it never fails. See the logs attached to this thread.
I found an image of comparison of genuine and faked FT232RL chips:
and my chip is rather similar to the faked one. Furthemore, my chip doesn't show the logo of the company (those three horizontal lines) and uppercase FTDI to the right of them. Funny.
