Got difficulties to upload firmware into ATmega644PA-AU (TQFP-44) over USB-TTL bridge connected to MCU UART0 port inside custom built circuit. Every time sketch uploading ends with error
stk500_getsync () attempt 1 of 10
stk500_getsync () attempt 2 of 10
...
An error occurred while uploading the sketch
USB bridge itself is functional and usual serial communication like command sending and message receiving by using Serial object happen just fine at all speeds between 9600 till 115200. Are it is bootloader related or there is something else to which I must look at?
The board framework is MightyCore, board 644, variation 644P/644PA. Tried all UART speeds from 9600 till 115200 and all pin configurations (Standard, Bobuino, Sanguino). CPU frequency is 16 MHz (external crystal). Bootloader flashing and sketch uploading over ICSP programmer (Atmel-ICE) happens without problems.
USB-TTL bridge is Infineon CY7C65223 in self powered configuration where bridge TxD is connected to 644s RX0 (PD0, pin 9), bridge RxD to 644s TX0 (PD1, pin 10) and bridge DTR# to 644s RESET pin (4) via 0.1 uF capacitor.
When you do that, the bootloader is erased. So if you have performed an upload via the programmer, you must always perform a "Burn Bootloader" operation before you can go back to uploading via USB-TTL bridge again. People seem to often fall into the trap of performing a sequence like this:
Connect programmer to board.
Burn bootloader so that I can upload via the USB-TTL bridge.
"While I have the programmer connected, I might as well try an upload via programmer".
Attempt an upload via the USB-TTL bridge and wonder why it fails.
It is expected that uploading over the USB-TTLD bridge will fail with the error you encountered if the bootloader is missing.
So if you haven't do so since the time you uploaded via the programmer, perform a "Burn Bootloader" operation and then try uploading via the USB-TTL bridge again.
I tried to burn bootloader at first over ICSP with UART0 for flashing set in configuration and then flash the sketch from Arduino IDE 2.x or Arduino Maker Workshop in VS Code over USB-UART0. On sketch flashing over UART - always the error I mentioned above. I admit some times it was due to blocked UART0 because of Serial Monitor or some other software who exclusively open the connection to UART. But now I'm out of ideas.
Finally fixed my flashing over USB problem. As turned out, flashing over USB-UART0 didn't worked also because firmware flashing over ICSP definitely erase existing bootloader. But that wasn't all. Even with restored bootloader flashing over USB-UART0 failed as mentioned above. So I dug deeper. Signal check with oscilloscope revealed permanently low logic level on CY7C65223 GPIO pin that was supposed to be DTR. That certainly wasn't right, it should be high when inactive. CY7C65223 datasheet describe several pin modes where Mode 0 on default should be 6-pin mode (with DTR). As we see, it is not the case. Infineon has USB configuration utility for CY7C65223 chip, however Windows-only and as turned out, it doesn't work with Wine (can't see ports). This forced me to reboot into Windows (blergh), where that thing works. As I expected, UART in CY7C65223 chip on factory settings was in 4-pin mode. Switching it to 6-pin mode enabled DTR and after power cycle ATmega644 flashing over USB-UART0 finally started working. Learned something new as well - presence of required signal pins in multifunctional USB to UART bridge doesn't guarantee that this or other expected signals are present on factory settings.
Got curious and checked some other similar USB to UART bridge chip made by different manufacturers (FTDI, Microchip, Silicon Labs etc.) datasheets. Found that they all need some fine-tuning in similar configurations like mine. Seems the only way how to avoid that is using bridge chips where DTR is on dedicated pin (such chips exist, but has ridiculous number of pins for my cause) or using CH34x (for me - no way, we want to be independent from China supplies) or changing the MCU to different one with built-in USB port. Interesting how manufacturers who make devices in ten thousands large batches deal with USB chip configuration? They should have some automated programming means because it isn't possible to manually flash such number of devices.