0
\$\begingroup\$

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';
        _delay_ms(1000);
    }
    return(0); 
}

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

\$\endgroup\$
  • \$\begingroup\$ Is there H/W loopback to enable DTR etc? \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 Jul 7 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\$ – Elliot Alderson Jul 7 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\$ – Mohamed Atef Jul 7 at 20:44
0
\$\begingroup\$

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.

\$\endgroup\$
  • \$\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\$ – Mohamed Atef Jul 7 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 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\$ – Mohamed Atef Jul 7 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 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\$ – Mohamed Atef Jul 7 at 18:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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