Can't upload code to my new board

I have designed arduino compatible diy board with Atmega328p-Pu. ,i have burned the bootloader for first time and the upload blink example to board and it didn't get any error. After that when i upload another code i got "avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x03"

i'm use ftdi programmer to upload code(i have already add 0.1uf cap DTR and 10K pullup resistor in my design)

When i press and hold reset button while compile and release when uploading its successfully uploading code.

i tried original uno ic with my board its work without any uploading error. also tried my new ic with arduino original board and didn't get error

how to solve this error

So your troubleshooting identified the board as the device with the issue. Can you post the schematic?

My schematic

I assume J5 is the programming header? Where else does the RESET\ go?

The error you are seeing I usually get when Windows lost sight of the FTDI board. I usually unplug the board USB cable and reinsert.

Yes its icsp header
Here the full schematic

I also tried unplug and repload . But still get error

My board work when i use original arduino Uno IC (no need to manually reset when uploading)

But When i use my new ic ( i got it from AliExpress without bootloader ) can't upload without manually rest :thinking:.. is it bootloader error?

The FTDI header J4 on your board has a non-standard layout. For example, DTR is nomally pin 6. The symptoms you describe are those of a missing DTR signal.

I changed the standard design.
I'm use this ftdi programmer. According to this dtr connect to pin 5
But no error with pin connection?

OK. The pin layout which Sparkfun uses, say for the Arduino Pro Mini, seems to be the most popular https://cdn.sparkfun.com/datasheets/Dev/Arduino/Boards/Arduino-Pro-Mini-v14.pdf . However, it looks like you have wired this special correctly based on that picture you have attached.

If a Serial program upload works correctly only when you manually operate the reset button, that does still sound like a DTR problem though.