I am using Nano 3.0 clone with CH340G USB-UART chip. Programming it with Atmel Studio and flashing with AVRDUDE. I have made the LED blink :)

I took the UART_EXAMPLE code from Atmel Studio(?) and tried my best to get the UART to talk to PC/Win 10 serial terminal (Putty, Termite). When I flash the .hex into the 328P, the TX and RX leds blink rapidly. After my code runs, the TX won't blink anymore. The RX led blinks if I send characters from serial terminal (as expected). But there's some disconnect in-between (my code)=>CH340G=>TX led.

Any ideas what I could check? Below are my functions to initialize the UART, send, receive bytes.

I have taken the ideas above and implemented them into the code. The full code is below.

W.r.t. to board frequency, there's an XTAL with marking "12.000" on the package. So I figured it to be 12 MHz XTAL. I have no easy means to check this atm. Even tried to pick it up with a SDR radio but the emission is too low to detected.

The board frequency is defined as this

#define F_CPU 12000000UL

However, the wrong baud rate would not stop RX/TX led from blinking?

1) The expected behaviour of the code would be:

- RX & TX leds blinking, typed characters returned to PC terminal.

2) Observed behaviour:

- The RX & TX leds blink while flashing, so no faulty leds. Also RX led blinks on application run when characters are send from PC terminal. But no TX on application, no returned chars.

The fuse values are lfuse = 0, hfuse = 0, efuse = 0. I used http://www.engbedded.com/fusecalc to decode these. Didn't understand all though, seem to be using EXTCLK and DIV-BY-8.

The yellow-highlighted argument means AS is talking to the bootloader on your Nano clone, not to an ISP programmer. The default bootloader on a Nano does not correctly report fuse values. Most bootloaders don't. >>No<< bootloaders are able the >>change<< fuses at all.

W.r.t. to board frequency, there's an XTAL with marking "12.000" on the package. So I figured it to be 12 MHz XTAL. I have no easy means to check this atm. Even tried to pick it up with a SDR radio but the emission is too low to detected.

The board frequency is defined as this

#define F_CPU 12000000UL

A genuine Nano runs at 16 MHz, not 12 MHz. So that's a bit peculiar.

I have made the LED blink :)

When you did, was the speed >>exactly<< as you expected it? How did you make it flash?

Forget about Atmel start and anything else for now. Confirm that an LED on port B (any pin) flashes >>exactly<< one second on and one second off. If it is flashing faster, then your board is probably running at 16 MHz.

"Experience is what enables you to recognise a mistake the second time you make it."

Does this mean that the CPU runs on internal 8 MHz RC oscillator or on the external 16 MHz crystal osc?

It means it's running at about 8 MHz. It tells us nothing about the clock source. However, we can probably infer that it's running from the RC oscillator, since an 8 MHz crystal should have resulted in exactly 15 seconds, not 15.5. The difference is likely a consequence of the inherently poor accuracy of the internal RC oscillator (although it can be calibrated).

You can read fuses in software, (although as mentioned few bootloaders are written to do this themselves). In this way you can be certain what the fuse values are.

How does

PINB = 0x3F;

achieves complementing the led state?

The datasheet is your friend.

Modern (i.e anything in the last ten years) have a toggle feature:

To read fuses, and display them in turn, on 8 LEDs connected to PORTD:

Be sure to wire up the LEDs with their cathodes GND and their anodes to the Arduino's pins (via resistor) rather than the other way (anodes to VCC, cathodes to Arduino's pins [via resistor]).

However, none if this is truly necessary. You now know what your F_CPU should be set to: 8000000UL. I haven't looked at your code, but provided it handles the USART correctly, this should get you up and running.

"Experience is what enables you to recognise a mistake the second time you make it."

The F_CPU is indeed 16 MHz. The toggling happens every 10 s as would be expected. I need to double check this still.

If it's 16 MHz, it would point to ext clocking as the internal RC osc would be 8 MHz.

I will also use the above code and leds to read the real fuse values. I will get back with more information in couple of days.

Edit: Would you know suitable JTAG programmers that would work with Win 10 and AS 7? The cheap ebay ones seem to be limited to AS versions below 5. If needed I will get ATJTAGICE from Microchip but getting something a little cheaper would be preferred.

I checked the CH340G datasheet, it needs a 12M crystal. So that's why.

I took pictures of front and back of the board, they are attached. In front.png, you can see the large can type crystal, the marking is not visible but it clearly reads "12.000". It's the crystal for CH340G. Next to AT328, there's a smaller metal package which is the 16M crystal. It has marking but it is not readable even with a lit loupe. This 16M crystal is connected between pin 2 (XCK) and pin 7 (XTAL1).

Next I will proceed to read the fuses. Also interested on your recommendations on programmers (see my previous post)

- Regardless of baud rate, why the TX/RX leds are not blinking, besides when flashing (expected, confirms that both leds are working) and when sending data from PC terminal (RX blinks, as expected, confirms USB-UART function).