Hi, I have found some unusual USART behaviour when i was trying to send characters from USART1 of my AT90CAN128 to the PC terminal. Below is the code that i have been using for the same. The problem is, what i am getting on my PC hyperterminal is some garbage. I did some calculations and found that there was a difference of 128 between the characters sent and the character received. For example, if i sent 0 i received 128 and if i sent 10 i received 10+128 = 138. The same code works well with the USART0. Also, i checked the waveforms on my oscilloscope by probing on the controller pin(TXD1) and on the transmit pins of MAX232 (before RS232). The patterns were almost identical. What i was wondering is that whether my USART was corrupt internally? While on chip debugging with Atmel's JTAG ICE mkII, i found that the USART's data register UDR1, in the IO register window, was still showing zero even when i have put a breakpoint at the place where i was assigning the data to the USART data register for transmitting. Kindly, help me overcome this problem. #include<avr/io.h> #define F_CPU 16000000L // F_CPU = 16MHz #define BAUD 9600 // Baudrate = 9600 void USART1_Init () { /* Set baud rate */ UBRR1H = (unsigned char) (((F_CPU/(16L*BAUD))-1) >> 8); UBRR1L = (unsigned char) ((F_CPU/(16L*BAUD))-1); /* Set frame format: 8data, no parity & 1 stop bits */ UCSR1C = (0<<UMSEL1) | (0<<UPM1) | (1<<USBS1) | (3<<UCSZ1); /* Enable transmitter and receiver */ UCSR1B = (0<<RXEN1) | (1<<TXEN1); } void USART1_Transmit(void ) { while ( ! ( UCSR1A & (1<<UDRE1))) ; UDR1 = trans_data ; // Place for breakpoint. trans_data++; if(trans_data >= 0x64) trans_data = 0x00; } void main(void) { unsigned char trans_data = 0x00; USART1_Init(); while(1) USART1_Transmit(); }
Unusual USART behaviour on AVR AT90CAN128
Started by ●July 12, 2007
Reply by ●July 12, 20072007-07-12
> I have found some unusual USART behaviour when i was trying to send > characters from USART1 of my AT90CAN128 to the PC terminal. Below is > the code that i have been using for the same. The problem is, what i > am getting on my PC hyperterminal is some garbage. I did some > calculations and found that there was a difference of 128 between the > characters sent and the character received. For example, if i sent 0 i > received 128 and if i sent 10 i received 10+128 = 138.Make sure the number of bits per byte, number of stop bits, and parity matches on the sender and receiver.> The same code works well with the USART0. Also, i checked the > waveforms on my oscilloscope by probing on the controller pin(TXD1) > and on the transmit pins of MAX232 (before RS232). The patterns were > almost identical. What i was wondering is that whether my USART was > corrupt internally?It's tempting to blame the UART but always exhaust all SW root cause possibilities first. It's embarrassing to call the tech support line and then later be shown the mistake is in SW. JJS
Reply by ●July 12, 20072007-07-12
Rav wrote:> Hi, > > I have found some unusual USART behaviour when i was trying to send > characters from USART1 of my AT90CAN128 to the PC terminal. Below is > the code that i have been using for the same. The problem is, what i > am getting on my PC hyperterminal is some garbage. I did some > calculations and found that there was a difference of 128 between the > characters sent and the character received. For example, if i sent 0 i > received 128 and if i sent 10 i received 10+128 = 138. > > The same code works well with the USART0. Also, i checked the > waveforms on my oscilloscope by probing on the controller pin(TXD1) > and on the transmit pins of MAX232 (before RS232). The patterns were > almost identical. What i was wondering is that whether my USART was > corrupt internally?If you have one that works, and one that does not, try running both at the same time, and compare the outputs with the scope. You can also try deliberate skew of the Baud divider to values either side of ideal, to check margins. -jg
Reply by ●July 12, 20072007-07-12
On Jul 12, 6:50 am, Rav <rav.tech...@gmail.com> wrote:> Hi, >[... USART problems ...]> > /* Set frame format: 8data, no parity & 1 stop bits */ > UCSR1C = (0<<UMSEL1) | (0<<UPM1) | (1<<USBS1) | (3<<UCSZ1);Get out the data sheet and read it. This line doesn't do what you think it does. For example, you're specifying two stop bits, not one. Regards, -=Dave
Reply by ●July 13, 20072007-07-13
On Jul 13, 3:03 am, Dave Hansen <i...@hotmail.com> wrote:> On Jul 12, 6:50 am, Rav <rav.tech...@gmail.com> wrote:> Hi, > > [... USART problems ...] > > > > > /* Set frame format: 8data, no parity & 1 stop bits */ > > UCSR1C = (0<<UMSEL1) | (0<<UPM1) | (1<<USBS1) | (3<<UCSZ1); > > Get out the data sheet and read it. This line doesn't do what you > think it does. For example, you're specifying two stop bits, not one. > > Regards, > > -=DaveMy apologies. It had been corrected to UCSR1C = (0<<UMSEL1) | (0<<UPM1) | (0<<USBS1) | (3<<UCSZ1);
Reply by ●July 13, 20072007-07-13
On Jul 12, 11:09 pm, Rav <rav.tech...@gmail.com> wrote:> On Jul 13, 3:03 am, Dave Hansen <i...@hotmail.com> wrote: > > > On Jul 12, 6:50 am, Rav <rav.tech...@gmail.com> wrote:> Hi, > > > [... USART problems ...] > > > > /* Set frame format: 8data, no parity & 1 stop bits */ > > > UCSR1C = (0<<UMSEL1) | (0<<UPM1) | (1<<USBS1) | (3<<UCSZ1); > > > Get out the data sheet and read it. This line doesn't do what you > > think it does. For example, you're specifying two stop bits, not one. > > > Regards, > > > -=Dave > > My apologies. It had been corrected to > UCSR1C = (0<<UMSEL1) | (0<<UPM1) | (0<<USBS1) | (3<<UCSZ1);Does that fix it? What is the value of UCSZ1? If it is 2 (which is what I would guess given the name), you are putting your UART into 7-bit mode rather than 8-bit. Regards, -=Dave