Avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt x of 10: not in sync: resp=0xxx

I got this clone Pro mini board without bootloader, after a hard time burning the bootloader onto it using a USBasp
However, i can only upload sketch via USBasp or on the first time uploading with UART converter, on the second time i cant get things to work, while the old sketch is still running on the board, tx and rx works fine

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x58
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x58
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x58
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x58
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x58
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x58
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x58
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x58
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x58
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x58

with each time failing to upload it returns different responses, no more 0x00 but 0x58(as shown), 0xee, 0x27, 0xac, etc.
i couldnt find a specific document about avrdude error code on the internet. And yes, i had its bootloader burned a several times but couldnt fix this issue

Hi @328trung.

Please note that when you do that the bootloader is erased. So you must remember to perform another "Burn Bootloader" operation when you want to switch to uploading sketches to the board via the UART converter.

Please add a reply here to tell us the exact connections you have made between the UART converter and the Pro Mini board.

What is that second "Burn Bootloader", or does it have something to do with my fuse bits?
Here is the values of FBs and LB in Arduino terminal when burning the bootloader

LF: 0x00
HF: 0x00
EF: 0x00
LB: 0x00

I didn't write the FBs and LB before burning bootloader
My pin connections are:
UART conv Pro Mini board
3.3v ----> VCC
TXD ----> RXD
RXD ----> TXD
GND ----> GND

It is the operation that replaces the bootloader on the microcontroller after you erased it by uploading a sketch using the USBasp.

No.

The fuse bits are automatically configured when you do a "Burn Bootloader" operation via Arduino IDE.

This explains the "can only upload once" behavior you are experiencing.

In order to upload, the bootloader needs to be activated. After performing a "Burn Bootloader" operation, the bootloader is in a state of perpetual activation so no special action is needed to activate it. However, once you have uploaded a sketch, the bootloader must be activated at the right time during the "Upload" operation. This is done by resetting the microcontroller. So if this reset is not occurring then you will experience the symptom of the first "Upload" after a "Burn Bootloader" operation succeeding, but then all subsequent uploads failing with the "not in sync" error.

Normally, we don't need to think about activating the bootloader because there is an auto-reset circuit on the Arduino board that does it automatically at just the right time during the upload. The auto reset circuit consists of the DTR or RTS (note, it's RTS not "RST") pin on the USB to serial adapter chip connected to the reset pin (marked RST on the Pro Mini board) via a 0.1 uF capacitor. You can use either DTR or RTS, it doesn't matter which. This circuit converts the signal on the DTR or RTS pin into a reset pulse at the right moment of the upload.

So the best solution is to make that missing connection between the USB to serial adapter and the Pro Mini board. After doing that, try uploading to the board again. Hopefully this time it will work as expected.


Some poorly designed USB to serial adapters don't break out the DTR or RTS pins. If you have one of these, you'll need to manually reset your Pro Mini in order to upload. When you don't have that auto-reset, and are resetting manually, you need to get the timing right. If you press the reset button too early, the bootloader will have already timed out by the time the upload starts. The tricky thing is that when you press the "Upload" button in Arduino IDE, it first compiles your sketch before starting the actual upload. So you need to wait until after the compilation finishes before pressing the reset button.

The way to get the timing right is to watch the black "Output" panel at the bottom of the Arduino IDE window. As soon as you see something like this:

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.

press and release the reset button.

The upload should now finish successfully.

1 Like

Thank you, your explains were clear and it all makes sense
My issue is indeed fixed, i think i would have to a make connection from the CH340G's DTR pin to a header for convenience.
Brought me more idea about how this microcontroller works

You are welcome. I'm glad it is working now.

In case you are interested in learning more about this "auto-reset" circuit, there is a nice technical explanation here:

Regards,
Per

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.