Is my bootloader corrupted?

Hello guys!

I had a AtMega328P that bootloaded and used for sometime. But recently I bootloded again forgetting that it was already bootloaded. I followed the standart Arduino as ISP procedure while I was bootloading it for the second time. But now when I try to upload code on the chip using FTDI adapter, it does not accept code giving me the error of:

avrdude: stk500_getsync(): not in sync: resp=0x00 (I guess this means something wrong with my bootloader because I checked my wirings billion times and changed the ports and reinstalled the IDE)

After it stopped accepting code I bootloaded it couple more time with the same technique. I also tried taking the chip out of an UNO board and programming my presumably corrupted AtMega328P with this UNO board. I also bought a USBasp module and tried programming my chip with it, it also did not work. But strangely the chip works when I plug it onto an UNO board itself.

I've been using Arduino but I've never learned much about the AtMega328 chip itself. Thus I'm new in microcontrollers and I don't know why this chip doesn't work after trying so many things.

What am I donig wrong? Am I wasting my time, is the chip already broken?

I would really really appreciate some insight on the many ways to burn bootloader to this chip and to program it.

Thanks!

(deleted)

Here is the little bootloader board that I use for bootloading operations. I have an 8MHz clock and all the ICSP connections connected. I intend to bootload and I use it as a 8MHz 3.3V Pro Mini as I did before accidentally burned the second bootloader.

I have read in the forum that actually this bootloading style removes the existing bootloader. (I'll try to provide quote for this) Do you think that might be the problem? If so how can I reburn the bootloader?

Update: Sorry that I cant' provide the photo. Website somehow gives error everytime I try to upload. I contacted the moderator about it. But I assure you that all the ISCP connections are correct. I mean,

MOSI on UNO(Top left on ISCP header) ---> Pin 17 on AtMega328
SCK on UNO (Middle left on ISCP header) ---> Pin 19 on AtMega328
RST on UNO (Bottom left ISCP header) ---> Empty
VCC on UNO (Top right on ISCP header) ---> Pin 8 & Pin 20 on AtMega328
MISO on UNO (Middle right on ISCP header) ---> Pin 18 on AtMega328
GND on UNO (Bottom right on ISCP header) ---> Pin 7 & Pin 21
D10 on 10 ---> Pin 1 on AtMega328
In addition a 10K pull-up resistor from Pin 1(on AtMega328) to VCC. And 2.2 pF caps from each leg of the clock to ground in AtMega328.

I hope this helps. Sorry about the photo :frowning:

You say you bootloaded it - but you don’t specify whether the bootloading procedure was successful or not… This is very frustrating to me as someone trying to help people on the forum. When you say it didn’t work - did the bootloading process itself generate an error, or did it succeed, yet you still weren’t able to upload? (In the latter case, particularly since it works plugged into an Uno, that seems strongly suggestive of improper connections to the USB serial adapter…

But strangely the chip works when I plug it onto an UNO board itself.

For uploads via USB?

Then the bootloader is fine, and the chip likely is as well. That it doesn’t work when you have it on breadboard and are trying to upload via an FTDI adapter, but does when plugged into an Uno is proof that the problem is your connections.

You should have TX of adapter connected to RX of arduino and vise versa (UART serial goes TX <-> RX). Ground of serial adapter should go to ground of the '328p, and the '328p must be powered, either through the serial adapter or from some other power supply. Finally, the DTR (or RTS - both work) of the serial adapter should be connected to one side of a 0.1uF ceramic capacitor, and the other side of that capacitor connected to ground. Reset should also be connected to Vcc through a 10k resistor. Both the Vcc and AVcc pins should be connected to power, and both Gnd pins should be connected to ground.

And, of course, you need the fuses set correctly for the clock source you have connected (for '328p, and everything shaped like it, use MiniCore so you don’t have to wonder if your board definitions are correct GitHub - MCUdude/MiniCore: Arduino hardware package for ATmega8, ATmega48, ATmega88, ATmega168, ATmega328 and ATmega328PB.

Also, there’s a reason the bootloader blinks a LED… Put an LED on that pin, and after bootloading it as you want to, see if the LED blinks when it’s not in the socket on an Uno (be sure to pulse reset low and see if it blinks then - the two most common problems people have with standalone boards is the autoreset circuit, and missing clock source - if, on the same board that it otherwise doesn’t work on, it does blink after you pulse reset manually, but doesn’t when you try to upload, then that demonstrates that the problem is your autoreset circuit.) If not, well, then, the bootloader isn’t running. If it does blink without any reprogramming when plugged into the socket on an Uno, - which in turn implies that it’s not set to use internal clock,

Sorry for the confusion I created. Every time I burn a bootloader it seems successful with no error, nothing but done bootloading message on the console.

About the connections, everything you say matches my connections except for the 0.1 uF cap that is going to the ground. My cap was going straight to DTR pin on the FTDI module. So I fixed that and connected to ground as you can see in the first image.

Yet still I got the error some error in the second pic. And I did use MiniCore as you can see my settings.

Also, there’s a reason the bootloader blinks a LED… Put an LED on that pin

Which pin you’re taking about here?

For uploads via USB?

Yes, I took out the microcontroller on the UNO and replace my succesfully bootloaded chip. And it had no problem uploading.

Also when I try to upload via FTDI, the third led on my standart FTDI chip blinks three times and stops and then sometime later it gives that above error. Does this have anything to do with what you’re saying? I mean it being an indicator of an error.

Sorry here is the second pic.

Also when I try to upload via FTDI, the third led on my standart FTDI chip blinks three times and stops and then sometime later it gives that above error.

Check out the C1 capacitor on the DTR lead. You need this for auto upload using the FTDI module.

https://camo.githubusercontent.com/ecd13cca83a58312bd01e20601084f108bfee1b4/68747470733a2f2f692e696d6775722e636f6d2f6270374b4939662e706e67

Correct me if I didn’t get it correctly. You are saying that I need the cap going straight into the DTR pin (on the FTDI module) without connecting to ground?

If your answer is yes, than I should tell you that my configuration was already like that before I switched it to the configuration that DrAzzy told me here

You should have TX of adapter connected to RX of arduino and vise versa (UART serial goes TX <-> RX). Ground of serial adapter should go to ground of the '328p, and the '328p must be powered, either through the serial adapter or from some other power supply. Finally, the DTR (or RTS - both work) of the serial adapter should be connected to one side of a 0.1uF ceramic capacitor, and the other side of that capacitor connected to ground. Reset should also be connected to Vcc through a 10k resistor. Both the Vcc and AVcc pins should be connected to power, and both Gnd pins should be connected to ground.

And in the pic you can see my previous configuration (which I think what you suggest) which also did not work and gave me the error I attached above.

And regarding the additional component you see in the bottom-left corner of the image I attached to my previous post; I use a 3.3V voltage regulator that is called the MCP1702. It successfully supplies 3.3V to the circuit which it converts it from FTDI's 5V supply.

So no power issues here.

Correct me if I didn't get it correctly. You are saying that I need the cap going straight into the DTR pin (on the FTDI module) without connecting to ground?

Yes. You need the cap between the DTR pin and Reset just like the link shows. The other way doesn't work.

If you still see the led blinking at the start it should work.

I solved the problem! I uploaded Nick Gammon's bootloader following this tutorial

(Best Way to Burn Arduino Bootloaders Tutorial! - YouTube).

You can also find all the beautiful explanations on Nick Gammon's website here

(Gammon Forum : Electronics : Microprocessors : Atmega bootloader programmer)

I burned the bootloader and it worked smoothly. I burned it as LillyPad (8MHz) option. Firstly, I went on uploading the basic blink sketch using my FTDI, it didn't work like before. It gave me the same error. After that I tried uploading using my UNO board. I removed the microcontroller on my UNO board and let the FTDI on UNO talk to my breadboard microcontroller directly. You can also find the steps here on Arduino's website.

https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard

By doing these steps, finally I was able to upload sketches to my AtMega328P after trying so many things. I still don't know why I had this problem in the first place tho. The chip was working up until I accidentally burned a second bootloader on it while it had one already. The bootloaders I burned were the standart ArduinoISP bootloaders.

Thank you for your time anyways. The problem is solved. Yet I would love to know why my chip stopped accepting code when I burned the second ArduinoISP (or Arduino as ISP) bootloader. If you have any ideas please do let me know! I'm dying to know!