trying to program an arduino nano with the CH340G usb chip on board and the programmer won't connect.
so i plugged in an uno clone and met the same problem.programmer not in sync...i selected the correct port by checking windows 'device manager'
the settings in programmer preferences are these;-
So, the bootloader may be set to either 57600 or 115200. To prove this open up AVRDUDE ( select F4 in GCODE and select AVRDUDE ), then select the com port, try 56700 or 115200, then select Detect.
Or, change to Arduino UNO @115200 in program prefs to try.
If AVRDUDE fails.. then post a photo the board. I am wondering if the AVR has a corrupt bootloader. This does happen, too often.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok. Open AVRDUDE ( select Function Key F4, type AVRDUDE).
In AVRDUDE select Arduino for bootloader using STK500 v1 protocol as the programmer, select the correct COMPORT, set Baud Rate as 57600, selected Detect.
If that fails.
Then, set Baud Rate as 115200, selected Detect.
If that fails.
Select the MCU as a ATmega328P and repeat the two tests above.
If that fails.
I suspect a duff bootloader. Change a PICKIt2 and upload a new bootloader to fix.
Or, is this a real AVR? Where is the ID on the chip?
I tried calling via Google Chat... no answer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i've tried all the settings,and it won't work in arduino either...it seems the bootloader IS bricked,as the arduino IDE reads the board signature OK but won't program.
these boards came with a blinky hex in them but code protect enabled! i made a new blinky sketch in arduino and it uploaded OK when i got them. one thing that worries me is this setting in AVRdude the bit where it says 'p m8'
Hello @ HackinBlack
You need to add the -F switch to the Uno and Nano AvrDude CLI in the Programmer Editor.
This switch Bypasses the "variant" check.
I had the same problem and the -F switch addition worked for me.
Cheers
Geoffrey Younger
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The -F parameter in AVRDUDE stands for "Force Signature Check." It tells AVRDUDE to ignore the device signature mismatch when programming an AVR microcontroller. Normally, AVRDUDE checks the target microcontroller's signature to ensure compatibility, and if there's a mismatch, it won't proceed. Using -F forces AVRDUDE to skip this check and attempt programming anyway.
However, be cautious when using this option, as it might lead to unexpected results if the wrong microcontroller is programmed or there are communication issues. It's generally recommended to use -F only if you're absolutely certain about what you're doing.
If you remove the -F then we should troubleshooting the specific AVR programming issue.
HackInBlack resolved his issue. The root cause we com port selection. I will post on the root cause analysis later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The added complication of AVRdude mis-reading the chip I.D. didn't help my stress levels 80/
the actual chips where the newer ATMega328PB parts;which came as a bit of a surprise to me.
AVRdude read them as 'mega328P' and programmed them without fuss.it was pure luck that they where code compatible. But with plenty of help from evan we got to the cause,eventually!
When the PB series was released. I worked with the AVRDUDE developers to get them to add the PB ( and the LGTs ) to AVRDUDE. They decided that as the PB was programmatically the same they would map the PB to older chip. Yep.. odd.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
trying to program an arduino nano with the CH340G usb chip on board and the programmer won't connect.
so i plugged in an uno clone and met the same problem.programmer not in sync...i selected the correct port by checking windows 'device manager'
the settings in programmer preferences are these;-
is the command line correct?
The short answer is 'yes'
So, the bootloader may be set to either 57600 or 115200. To prove this open up AVRDUDE ( select F4 in GCODE and select AVRDUDE ), then select the com port, try 56700 or 115200, then select Detect.
Or, change to
Arduino UNO @115200in program prefs to try.If AVRDUDE fails.. then post a photo the board. I am wondering if the AVR has a corrupt bootloader. This does happen, too often.
i got the UNO to work,but the nano is not.the com port is correct but i'm not sure about the AVRDUDE programmer choice...is this even the right one?
Last edit: HackInBlack 2025-03-18
these settings don't work
Ok. Open AVRDUDE ( select Function Key F4, type AVRDUDE).
In AVRDUDE select
Arduino for bootloader using STK500 v1 protocolas the programmer, select the correct COMPORT, set Baud Rate as 57600, selected Detect.If that fails.
Then, set Baud Rate as 115200, selected Detect.
If that fails.
Select the MCU as a ATmega328P and repeat the two tests above.
If that fails.
I suspect a duff bootloader. Change a PICKIt2 and upload a new bootloader to fix.
Or, is this a real AVR? Where is the ID on the chip?
I tried calling via Google Chat... no answer.
i've tried all the settings,and it won't work in arduino either...it seems the bootloader IS bricked,as the arduino IDE reads the board signature OK but won't program.
these boards came with a blinky hex in them but code protect enabled! i made a new blinky sketch in arduino and it uploaded OK when i got them. one thing that worries me is this setting in AVRdude the bit where it says 'p m8'
i think its defaulting to a mega 8?
Last edit: HackInBlack 2025-03-18
Hello @ HackinBlack
You need to add the -F switch to the Uno and Nano AvrDude CLI in the Programmer Editor.
This switch Bypasses the "variant" check.
I had the same problem and the -F switch addition worked for me.
Cheers
Geoffrey Younger
@Geoffrey
The -F parameter in AVRDUDE stands for "Force Signature Check." It tells AVRDUDE to ignore the device signature mismatch when programming an AVR microcontroller. Normally, AVRDUDE checks the target microcontroller's signature to ensure compatibility, and if there's a mismatch, it won't proceed. Using -F forces AVRDUDE to skip this check and attempt programming anyway.
However, be cautious when using this option, as it might lead to unexpected results if the wrong microcontroller is programmed or there are communication issues. It's generally recommended to use -F only if you're absolutely certain about what you're doing.
If you remove the -F then we should troubleshooting the specific AVR programming issue.
HackInBlack resolved his issue. The root cause we com port selection. I will post on the root cause analysis later.
The added complication of AVRdude mis-reading the chip I.D. didn't help my stress levels 80/
the actual chips where the newer ATMega328PB parts;which came as a bit of a surprise to me.
AVRdude read them as 'mega328P' and programmed them without fuss.it was pure luck that they where code compatible. But with plenty of help from evan we got to the cause,eventually!
Last edit: HackInBlack 2025-03-19
A good point.
When the PB series was released. I worked with the AVRDUDE developers to get them to add the PB ( and the LGTs ) to AVRDUDE. They decided that as the PB was programmatically the same they would map the PB to older chip. Yep.. odd.