Building my own Arduino uno: Problems with CH340G

Hello,

I am currently trying to build my own Arduino Uno board with some cool features:
Features I added:

  • USB type C port
  • double row Pins
  • and an extra 5v Net for all of the system components

After I had some problems with uploading the bootloader, I ordered some new Pcbs and the Atmega 328p AU is now working...

I burned the bootloader and was successful in uploading the Blink sketch through the ICSP port.
Then I tried to upload a sketch using the USB port. I build 3 boards of wich only one was recognized by the PC (I tried to Pcs running Windows 10 with the ch340g drivers installed).
When I put the one board that got recognized directly into the front ports of my PC Windows gives me Warning, saying that the USB device wasn´t recognized or doesn´t work correctly. (I tried both USB 2.0 and 3.0)
BUT when I plug it into my USB Hub the Arduino board shows up in the Arduino IDE. Sadly, when I try to upload a test sketch, an error shows up:
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x35
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x35
...

So tried uploading the bootloader again multiple times, but that didn´t work either.

When I plugged the board into my Laptop, I always get the windows error message.

The other two boards I build don´t even put up an error message. (I´ve checked for shorts and they visually looks ok)

Maybe you have some Ideas / suggestions / tips that could help me.
Thanks.

A clue is here:

I burned the bootloader and was successful in uploading the Blink sketch through the ICSP port.

A sketch, in your case, the blink sketch, loaded via the ICSP header will overwrite the boot loader, so the errors are not surprising.
Try re-installing the boot loader then load the sketch via the USB socket and, if that fails, some other method (say a USBTTL device) which uses the TX/RX pins of the ATMega328P to load the sketch via the bootloader instead of directly hammering it in through the ICSP header.

Your PC might not have the right drivers to support the CH340G, so you could start looking there, but a test with a USBTTL device (or an Arduino Uno configured as one) might help isolate the problem.

Edit
Here is another schematic using the CH340G and an ATmega328P but where the TX and RX are crossed over between the chips: Arduino Uno R3 schematic CH340.

You may have got caught out if you based your design on an early version of this: http://actrl.cz/blog/wp-content/uploads/nano_ch340_schematics-rev1.pdf. Look at the revision history at the top.

Without finding a data sheet for the CH340G I can only make the obvious comment that they can't all be right.

Looking at your diagram, I am wondering about the logic behind taking your RxD and TxD from those points.

If my calcs are correct, and they may not be, you only vary the signals between 5V down to 1.6V via a 1K resistor, 1.6V across each resistor and 1.8V (as an estimate) across the LED (total = 5V). Is that good enough to drive the 328?

So yes, as suggested by @6v6gt, try uploading via some USBTTL device basically bypassing the CH340G.

Willem.

First of all, thank you for your replies!

6v6gt:
A sketch, in your case, the blink sketch, loaded via the ICSP header will overwrite the boot loader, so the errors are not surprising.
Try re-installing the boot loader then load the sketch via the USB socket and, if that fails, some other method (say a USBTTL device) which uses the TX/RX pins of the ATMega328P to load the sketch via the bootloader instead of directly hammering it in through the ICSP header.

So I tried it: I uploaded the bootloader again over ICSP and then tried to upload a sketch using the usb, but that didn´t work. Then I tried using an USBTTL device, but got the same error...

Did you try swapping the Tx and Rx pins yet?

6v6gt mentioned it but didn't see if you'd tried that yet. I've screwed them up more than once.

Wesstun:
Did you try swapping the Tx and Rx pins yet?

6v6gt mentioned it but didn't see if you'd tried that yet. I've screwed them up more than once.

I did swap the RX / TX pins while testing with the USBTTL device, but it gave me the same error as before...

I guess that the serial connection between the CH340G and the ATmega328p is incorrect. R3 to R6 and the 2 leds could also interfere with any attempts to use a USBTTL device to directly program the ATmega328p via its RX/TX pins.

If the wiring is indeed incorrect, you have to cut the tracks at some point and bridge/cross them as required. Before bridging them, try again with the UBTTL device.

May I make a suggestion? You need to debug this step by step.

Do as @6v6gt says - somehow isolate the CH340G from the 328P, even if it means cutting the relevant tracks. Hook the USBTTL device directly to RX/TX. Upload a sketch using ISP (you said ISP uploading works) which prints to the serial monitor. ("Hello world" in the loop?).

If you do not see the messages on the serial monitor you have something else wrong. Once that works take it further. First get the comms working, then worry about uploading via USB.

Willem.