This has been driving me absolutely insane for the past couple days. I soldered together an Atmega644P standalone circuit, and also added a CH340G usb to serial converter as well with all the necessary components. But for the life of me, I simply can't get sketches onto the chip. I checked my wiring countless times in multiple places with a multimeter, checked if I was using the correct bootloader, updated my boards manager, etc. I think I tried everything under the sun. All my google search links are purple as well. I programmed MightyCore on the 644P with my Bus Pirate, and I'm pretty sure the fuse bits and lock bits were properly set. But just in case, I bootloaded it with an Arduino UNO as the ISP but it still didn't work. All of my errors have been stk500_getSync() errors, which as many of y'all know greatly narrows down my problem. I've attached a schematic of an Arduino Nano which I followed pretty much exactly to make my board, except I replaced the 328P for a 644P. I also didn't include RX/TX LEDs yet and also didn't put any diodes in since I couldn't find any. I also attached photos of my board.
Here are a few notable quirks. Pay attention here as these might give you some clues to narrow down the problem.
I DID get it to work twice, although I'm not sure how. It successfully downloaded and ran a simple blink sketch through the CH340G usb to serial circuit, but when I tried programming it again (literally just clicked "Upload" again with no changes to the circuit or program) it didn't work again. Sometimes, it would look like it was working but suddenly stop in the middle of the programming process and throw the good ol' classic STK500 getsync() error.
I can program the 644P through the ISP header with my bus pirate. Everything works fine if I program it that way, but I really want to get the USB-serial part of my circuit working since that's kinda the highlight of my project.
I tried multiple 644Ps as well as an Atmega16. None of them worked. Again, they all worked when the sketch was loaded via the ISP header with my Bus Pirate, but never when I tried uploading through the USB port.
There's like a 5-second delay when booting up for the first time. When running a simple blink sketch, the program always starts 5 seconds after I apply power to the circuit. Not sure if that's supposed to happen. Weirdly enough, if I disconnect the 10k ohm pull-up resistor I have on the reset line(upper-left of the back of my circuit), the boot delay goes down to about 3 seconds.
I connected a USB to Serial converter I had laying around to my ATmega644p board. I know it works because I've used it many times before. It did not work as well, meaning my problem likely lies in the 644, not the CH340G.
I will update this thread with any more discoveries or things I may have forgotten to write in the first place. I'm a novice hobbyist so maybe I just forgot something really simple but it's driving me insane and I'm just desperate to get my circuit working.
They are the small yellow-orange 0.1uf capacitors on the top-left of the board, 4 of them in a vertical row. I also have 10uf ones surrounding the 7805 voltage regulator and power switch, next to the USB port. Should they be closer to the microcontroller? I didn't think it would really matter for a relatively simple circuit like this one.
Can you confirm that the auto-reset works?
If you've loaded Optiboot on the 644, the builtin LED (do you have one? Maybe connect one up temporarily to wherever the MightyCore bootloader thinks it is), it should blink rapidly three times each time the CPU is reset, including at the start of a sketch upload. (though I guess if you have JUST the bootloader loaded, it'll do those three flashes continuously, every one second or so.)
Are you sure that TX/RX aren't swapped? It's a common mistake, but I can't quite tell from the pictures. (neat wiring job - better than average use of colors!)
sorry for the late reply, and I really appreciate our help. I don't know for sure, but it seems to reset right before uploading. I burned a blink sketch + the bootlader together onto the 644P through via ISP, and the blinking stops for a brief moment and starts again right before uploading. That's also when STK500 errors show up. It's confusing because the program stops, meaning it's resetting, but it starts again, which I'm pretty sure isn't supposed to be happening when entering programming mode. So I don't think the 644P is resetting properly, which is where my problem likely lies. No idea how to fix it tho, since I think my reset circuit is done correctly. I've gone over it multiple times. Also, I'm pretty sure RX/TX lines are soldered correctly. CH340G's RX goes to the Atmega644p'S TX, and vice versa, right?
No, that's normal. If the bootloader does see "proper" commands to upload a new sketch, it will start running whatever sketch is already present, after a little more than one second. So it sounds like your RESET is OK.
CH340G's RX goes to the Atmega644p'S TX, and vice versa, right?
Huh, if my reset is OK, I can't possibly figure out where my circuit is going wrong. I connected an LED to the proper pin and it blinks a pattern just like it's supposed to according to the Mightycore bootloader documentation. Can it be something related to building it on a protoboard and not a PCB? I didn't clean my flux, but as far as I know the one I use is not conductive and I don't see any shorts.
When burning the bootloader, did you also set the settings for clock (i.e. external 16 MHz), processor type, processor variant, bootloader (yes, uart0)?
Yes, I've set them correctly. ATmega644P, external 16MHz, Brown-out detection at 2.7v, EEPROM retained, compiler disabled, standard pinout, and UART0. I've even tried both UART ports and switched USB cables as well
Since you have LEDs for RX and TX on your board, you can connect the board to the PC, select processor and port in the Arduino IDE, then open the serial monitor and set to 9600 baud locations. The RX / TX LEDs should flicker briefly. Then you can simply send any longer string of characters to the board and watch the LEDs. The RX-LED (your green LED) should flicker during the transmission, which indicates that the data has been received.
I don't have RX/TX LEDs. The green LED is for power and red LED is connected to PB0. I will try this out tho. Also, shouldn't I set the baudrate to 115200? That's what's recommended for external 16MHz micros according to the documentation.
Ok, so I wired it exactly as shown on the schematic I attached in my post. The TX LED (connected to TX on the CH340G and RX on the 644P) stays on very dim, and occasionally flickers between different levels of brightness, which I assume isn't supposed to happen. I think maybe my board's power supply is flaky? The RX LED stays off. Whenever I send something over the serial monitor, the TX LED flickers when I hit enter but the RX LED still stays off. Again, my TX LED is connected to TX on the CH340G, not the 644P. Maybe I'm calling it opposites. I'm confused lol
So, it actually works like this with the LEDs: The LED that flickers when you send data from the viea serial monitor to your board is the RX LED, because the board RECEIVES data. And the LED that flickers when the processor, i.e. the ATmega644, sends (TRANSMITT) data to the serial monitor, is the TX LED.
However, I have found that the TX-LED, i.e. the LED that lights up / flickers when the ATmega644 is sending data, really only lights up, not during the reset, opening the serial monitor, or when connecting the board to USB. And since there is currently no sketch on your processor that sends data to the serial monitor, this LED is also not active.
However, it should by no means be the case that one of the two LEDs is active when the board is connected to the USB, only with the bootloader and without data from the serial monitor being sent to the board. Otherwise you either have a problem with the operating voltage or a mass problem. because in the idle state, RX and TX are at HIGH potential, so that the LEDs are off. I've used the CH340G several times. And also the ATMega 644 and the 1284 in connection with the CH340G, and that usually works without any problems. Maybe really a problem with the structure on your prototype board.
Ok, weirdly enough the LEDs seem to be working somewhat properly now. I did not change anything in the circuit, I just woke up and plugged it in to a power source and the bootloader LED does its usual blinking, and both RX/TX LEDs stay low. When I try uploading a program, the RX LED blinks briefly 3 times, relatively dimly, and stays low again. It also blinks once when I plug the board into a power source. When I send stuff over the serial monitor, it blinks on normal brightness every time I press enter.
Alright y'all, I finally solved it. I gotta be the dumbest "engineer" in history.
I had an 8MHz crystal connected to my board this whole time! I thought it was 16MHz so I set everything to 16, not 8. Strangely enough, the bootloader burnt successfully every time, but UART wasn't working since I set it to work with 16MHz, not 8 like I had on my actual hardware. I was building my circuit again on a breadboard to try to re-create the issue, and I suddenly realized this mistake. I'm going to study electrical engineering in college and I wonder how many F's I will get for simple mistakes like this one lol.
Holy cow, yes, that's a very mean mistake. Sorry for my abstinence, but I couldn't think of why it couldn't work, I checked your photos, especially the RX / TX lines and everything around the CH340G, I couldn't see any errors. And the connection with the USB worked. But now it is of course clear, because the UART, the baud rate in particular, of course, depends on the clock.
I am very happy that you found the bug and it works now.
