Homemade "Uno" executes first line of code, then stops?

I have been experimenting with making my own Arduino Uno board. I have a breadboard version that works great, i connect the end of my USB cable into a CH340G chip, and that connects to the atmega328 chip via the Rx Tx and DTR (reset line). I can upload sketches and communicate over serial, everything works as expected.
I recently finished building my PCB version of the breadboard design. The only difference i can see is that i'm using SMD components (except the 328 chip, it's still the breadboard version, and can be removed) and it's not behaving how it should. This is going to sound weird, but i think the atmega328 chip only does the first line of code, and then just stops.
When i upload the Blink sketch, the IDE says "upload complete" etc, and shows no indication of anything going wrong. However when i look at the PCB, the led on pin 13 is not blinking, it's just constantly on (only pin 13 is HIGH). I push the reset button, and pin 13 does it's usual "reset light display", but it just goes back to keeping pin 13 high forever.
I change the code to put the led onto a different pin, and now only that pin is stuck on HIGH.
I change the code and put: digitalWrite(led,LOW); as the first line. Now the led does not turn on.
I change the code and put delay(5000); in the setup() loop. Led does not turn on now.
??
now it gets even stranger:
Next i uploaded the normal blink sketch onto the 328, then i removed the 328 from the PCB and put it into a genuine Uno device, power it up and the same thing happens, pin 13 is stuck on high.
Now i try and upload the blink sketch onto the 328 chip using the genuine Uno device, i remove the 328 chip and put it in my pcb, and guess what happens.. it blinks as it should !!!! ???
I (use the genuine arduino) upload a sketch that outputs the position of a potentiometer over serial, and put it into my pcb, and it works as it should, so serial output works too.

So now i'm stumped on how to approach this problem.
It's almost as if only part of the code gets uploaded when i try to upload using the PCB.
If i remove the 328 from the PCB and rewire the RX and TX lines from the CH340G chip to a HC-05 module, i can communicate with it without any problems using AT commands. ??

I've checked all my pcb traces, i do use a lipo battery to power, but i've tried a reliable power supply incase it's a power issue and the problem remains, and i never had a power problem when the lipo powered the breadboard version. I even added a 100uF cap across power and ground.

I'll admit that my PCB traces are a bit spaghetti like, with power lines and data lines jumping over and under each other, could it be that?
I've tried changing the board type i'm uploading to, Uno, nano, etc, they all just used to work, but not on the PCB version.

It could be. Have you got any decoupling capacitors on your PCB layout?

That suggests to me like this may be the only decoupling capacitors you have.

1 Like

Do you have a scope at hand to perform various tests?

1 Like

my circuit

I have uploaded a picture of my circuit, i have a 0.1 uF capacitor across pins 7 and 8, maybe i should add another across pins 22 and 20 ?
i just realised that the 0.1uF cap across AREF and GND was not in the original breadboard design, it's just on the PCB circuit, i doubt that's causing it though.

the 100uF cap isn't in my picture, i removed it once i realised it didn't make a difference

I have a simple oscilloscope from a hobby kit years ago i just learnt a few simple things, but i'm more than up for trying to remember how to use it !! :smiley:
that reminds me, when i upload the blonk sketch the first time the LED remains on and it's quite a bright light. If i upload the sketch again, the led is a dimmer light. If upload the sketch again, it is a bright led light again, back and forth etc etc

This can indicate a clock generation problem - therefore the scope.

1 Like

Thanks for the circuit. It could be that pins 9, 10 and 12, need to be set to the correct level before the CH340 will operate.

It could be this chip that is causing the problem rather than the Atmega328.

I would try writing code that just sends stuff to the serial monitor. Program it on your true Arduino and then transfer it to your PCB. See if you can see stuff coming out on your scope.

It might also be worth trying the RTS rather than the DTR to reset the Arduino but that is a long shot. I have not used the CH340 in a design so I am not sure how it reacts in practice. Again look at the DTR pin on your scope to test it is doing what you expect when first connected up to the UART.

1 Like

Thanks for the reply, the circuit works fine on the breadboard version, both chips on the pcb seem to work fine in other circuits, but together something is going wrong maybe??
I can upload a sketch using my genuine Uno onto the 328, and then put it into the pcb and it succesfully prints strings of data over the serial monitor.
I can also remove the 328 chip from the pcb, and redirect the Rx Tx lines from the CH340G chip to a HC-05 module, and i can successfuly give AT commands.
I don't understand how the arduino IDE can think it's successsfully uploading the code, whilst uploading a "watered down" version of it that won't execute fully, even when placed in a genuine Uno. If i remove the Rx Tx or reset lines and try to upload the IDE complains straight away, "can't connect" etc
So the two chips are definitely talking to each other, but the data uploaded is getting "misused" by the 328?
hmm
i've got my oscilloscope out (DS0138) and i'm going to try and find some difference between the breadboard version and the pcb version.

Thanks for the reply, I think you're right, i'm gonna see if i can find any differences between the breadboard version and the PCB version with my scope.

Shouldn't the TX/RX leds be connected to 5V instead of GND via their 2K2 resistors?

1 Like

well spotted! I drew my circuit wrong, it does in fact go to 5v like you said :smiley:

What is the purpose of the 1k resistors on RX/TX. :face_with_raised_eyebrow:

1 Like

The combination of the 1K and 2.2 K ohm resistors is to shift the output voltage on the Tx line from 5v down to 3.3 v. Some devices like the Hc-05 module use 3.3v logic, 5v could damage the module. 3.3v when high is also enough to to trigger the high on 5v logic devices, like the Arduino, so can be used on 5v devices too :smiley:

strictly speaking i only need it on the TX line, Rx can be wired directly

Not with that wiring, even if you correct it as stated in post #12. The LEDs drop around 2V each.

Please post the correct wiring diagram.

This is a valid level shifter for 5V output to 3.3V input (the signal moves from right to left, contrary to convention).

EDIT: fixed, thanks @6v6gt

1 Like

i think you're onto something here, i'm worried the smd led is reducing the voltage too muhc to trigger the arduino, i'm going to test the lines directly to see what happens, thanks !

They serve no purpose and prevent the Tx output (Arduino Rx input) from reaching LOW.

Get rid of them.

1 Like

i think this could be the issue, however the amended circuit in the picture still does work on the breadboard, i use red LED's though, i think they have lower voltage requirements to the ones i have on the PCB?? i will test the lines directly and see what happens

I thought i was replicating the rx /tx led's like on the Uno?, so you can see when modules are communicating?
I will test all rx/tx lines directly, fingers crossed!! :smiley: