I used PL2303hx to connect my PC to the chip and I did the correct connections and installed the driver of the IC and the program I wrote was simulated succesfully on proteus:
But when I do it on the reality the blue LED in PL2303hx blinks every time I send data from the chip to my PC (e.g. if I make the delay time 1 second it blinks each 1 second )but data is displayed is just <0>

the code to just make sure that it works fine :

#define F_CPU 16000000
#include <avr/io.h>
#include <util/delay.h>

int main(void)
    uint16_t UBRR_Value = 103; 

    UBRRL = (uint8_t) UBRR_Value; 
    UBRRH = (uint8_t) (UBRR_Value >>8); 
    UCSRB |= (1<<RXEN) | (1<<TXEN); 
    UCSRC |= (3<<UCSZ0);  

    while (1)
        while (! (UCSRA & (1<<UDRE)));
        UDR = 'B';

and the fuse bits CKSEL and CKPOT are set to fit with 16MHz external crystal just like written in the code. enter image description here

  • \$\begingroup\$ Is there H/W loopback to enable DTR etc? \$\endgroup\$ Jul 7, 2019 at 17:25
  • \$\begingroup\$ Try verifying the USB interface separately from the AVR. Without the AVR connected to the PL2303, connect RX to TX directly at the PL2303. Use a simple terminal program, like Putty, to send characters to the PL2303...are they sent back to you? \$\endgroup\$ Jul 7, 2019 at 17:30
  • \$\begingroup\$ @ Elliot Alderson thanks for your comment The problem got solved .. yet Putty is a very powerful software I liked it \$\endgroup\$ Jul 7, 2019 at 20:44

1 Answer 1


Emulators are not same as real world and may not be correctly made. In some AVRs like the ATMega32A, the UBRRH and UCSRC registers are accessed through same address, so you have the wrong sequence to access them. Please read the datasheet section about how to use the registers properly. Basically, don't do a read-modify-write operation to UCSRC, as reading it will actually read UBRRH first, and a second read will read UCSRC. And when writing, use the URSEL bit correctly to select between UBRRH and UCSRC. Basically what happens now is that you set the UBRRH register to non-zero value and thus the baud rate not 9600 but something really slow (about 609 BPS) which the PC interprets as receiving 0 with FRAMING ERROR as seen in the screen shot.

  • \$\begingroup\$ Thanks for your concern but it was A matter of code segment #define BAUDRATE 9600 #define BAUD_PRESCALLER (((F_CPU / (BAUDRATE * 16UL))) - 1) \$\endgroup\$ Jul 7, 2019 at 18:07
  • \$\begingroup\$ Maybe you changed something else as well. That still makes baud rate divisor of 103 like in the original code so it was not the problem. \$\endgroup\$
    – Justme
    Jul 7, 2019 at 18:13
  • \$\begingroup\$ it's in the UL and I can't figure why UL is just what I changed I think this is a C type thing \$\endgroup\$ Jul 7, 2019 at 18:16
  • \$\begingroup\$ Because on AVRs int type is 16 bits and long int type is 32 bits. 9600*16 does not fit to int so you need the type to be UL. But as you did not originally post that part of the code, how could we see the error. \$\endgroup\$
    – Justme
    Jul 7, 2019 at 18:33
  • \$\begingroup\$ I posted uint16_t UBRR_Value = 103 ; And you thought I used the registers in a wrong way I didn't mislead anyone here , I just searched the internet for A similar code , Why so defensive ? \$\endgroup\$ Jul 7, 2019 at 18:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.