UART/HyperTerm: I *THINK* This Is a New One

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have a simple UART program set up to send/receive fgrom HyperTerm. I send a "P" from Hyperterm, and my program should then respond back repeating with a particular char. Using a ATmega325A w/ the internal oscillator (8MHz). I initially tried a 38.4 kbps setting (value of 12 gives me 0.2% error @ 8MHz).

Here's the issue: I can send data from the micro to Hyperterm consistently IF the value is below 0x7F. As soon as the most significant bit becomes a "1", all hell breaks loose: sending a 0x80, I get the char for 0xC7, for example (Latin Cap C w/ cedilla according to my chart), instead of the Euro currency symbol I expect.

Here's what I've tried:
1) Changing baud rates. Went all the way down to 4k (103 in BRR). Exact same results.
2) Tweaking OSCCAL. I was able to go up or down about 12 steps in each direction with the same results. Any more, my application wasn't receiving the correct char I send from Hyperterm to kick off this transfer.
3) Verifying Hyperterm settings: set for ANSI, incoming ASCII data forced to 7-bits NOT checked

Anyone have any ideas?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use baud rate xtal, 8 bits, 1 start, no parity, 1 stop bit. Same settings for terminal and, avr. Also no handshake on terminal, unless using hardware for that.

It all starts with a mental vision.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the reply. I have triple checked these settings in both Hyperterm and the 325A, and am quite sure this is what I'm using.

UART Init code:

void USARTInit(unsigned long clBaudRate)
{
   BAUD_RATE_REG = clBaudRate;                                                  //Set Baud rate to received value
   USART_CNTRL_C = ((1<<USART_CHAR_SEL_1)|(1<<USART_CHAR_SEL_2));               //Asynchronous mode, 8-bit character size
   USART_CNTRL_B =(1<<RXEN0)|(1<<TXEN0);                                        //Enable the receiver and transmitter    
   return;
}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Using a ATmega325A w/ the internal oscillator (8MHz).
The internal oscillator can be as much as 10% off. Either use an external crystal, or find a way to calibrate the internal oscillator (though this still requires some external frequency source to calibrate against).

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi wrote:
Quote:
Using a ATmega325A w/ the internal oscillator (8MHz).
The internal oscillator can be as much as 10% off. Either use an external crystal, or find a way to calibrate the internal oscillator (though this still requires some external frequency source to calibrate against).

Understood, and I do plan on adding a crystal to this design. However, "the way" to calibrate the internal oscillator is via the OSCCAL register, which I tried, as mentioned above. I also can't see how the oscillator could affect ONLY the most significant bit, causing complete chaos. I tried sending 5-6 different chars with the most significant bit a "1", and could figure out NO correlation between what I sent and what Hyperterm received (i.e., this wasn't a simple case of something being shifted, or a 1 getting left of, etc.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

. I also can't see how the oscillator could affect ONLY the most significant bit,

Because it's the last bit transmitted and the error is cumulative.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Agreed -- the error is cumulative, so each succeeding bit in the transmitted byte is slightly more out of place until one bit fails to be read properly.

Sometimes adding an extra stop bit will help.

Dr. David Harris OpenLCB Development Team openlcb.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Sometimes adding an extra stop bit will help.

Using a reliable clock in the first place is probably a better solution ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh yes, agree. Choose your crystal so there is zero error for your chosen baud rate.

Dr. David Harris OpenLCB Development Team openlcb.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Though its possible, I don't think this can be blamed on the RC oscillator in this case.
The fact you poked varying values into OSCCAL seems to bear this out.

I would try a different terminal program, ideally one which allows you to view 'raw' incoming data.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nobbyv wrote:
.... sending a 0x80, I get the char for 0xC7, for example (Latin Cap C w/ cedilla according to my chart), instead of the Euro currency symbol I expect.

Your sending side is just fine!

I believe you have the wrong expectation to what the 0x80 will give you.
When I hold then press 128 on the numeric keypad I get Ç.
See! I just did it. ;-)

You should better try a terminal program that can print the hex codes of the received data. Try Token2.

Einar Sjaavik

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is hyperterminal supported by Windows Seven? Is it a safe bet to invest time in it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nobbyv wrote:
Have a simple UART program set up to send/receive fgrom HyperTerm. I send a "P" from Hyperterm, and my program should then respond back repeating with a particular char. Using a ATmega325A w/ the internal oscillator (8MHz). I initially tried a 38.4 kbps setting (value of 12 gives me 0.2% error @ 8MHz).

By now you know why internal oscillators are not suggested around here :)

nobbyv wrote:

Here's the issue: I can send data from the micro to Hyperterm consistently IF the value is below 0x7F. As soon as the most significant bit becomes a "1", all hell breaks loose: sending a 0x80, I get the char for 0xC7, for example (Latin Cap C w/ cedilla according to my chart), instead of the Euro currency symbol I expect.

Funny, in my charts, 0x80 is Latin Cap C with cedilla, most definitely not an Euro currency symbol. Perhaps you are looking the letter 0x80 from different code page than what your terminal uses?

See the extended ASCII chart for example, http://www.asciitable.com/

nobbyv wrote:

1) Changing baud rates. Went all the way down to 4k (103 in BRR). Exact same results.

That is because each standard baud rate (38400, 19200, 9600, 4800) still has the exact same baud rate error of 0.16%, it only proves the hardware should work because it is consistent with all baud rates.

nobbyv wrote:

2) Tweaking OSCCAL. I was able to go up or down about 12 steps in each direction with the same results. Any more, my application wasn't receiving the correct char I send from Hyperterm to kick off this transfer.

Good, then you are within the error margin.

nobbyv wrote:

3) Verifying Hyperterm settings: set for ANSI, incoming ASCII data forced to 7-bits NOT checked

ANSI could mean the ANSI escape codes to control cursor and select colors, not the ANSI code page where 0x80 is Euro currency symbol.

Install something like RealTerm to see the data instead of characters.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jepael wrote:

Funny, in my charts, 0x80 is Latin Cap C with cedilla, most definitely not an Euro currency symbol. Perhaps you are looking the letter 0x80 from different code page than what your terminal uses?

See the extended ASCII chart for example, http://www.asciitable.com/

Install something like RealTerm to see the data instead of characters.

That was it exactly. The Extended characters in the ASCII table I found here:
http://www.ascii-code.com/

Doesn't match the one that Hyperterm uses, which is the one at the url you posted. I assumed that Hyperterm was compliant woth ISO 8859-1, which was a foolish assumption. So I WAS actually getting the correct chars. Using a better terminal program that showed the actual data would have clarified this for me a lot sooner; I am off to download one now.
Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you can I'd highly suggest using a different terminal program to do your serial debugging. I personally find
Bray's Terminal to be very good.

https://sites.google.com/site/terminalbpp/

Among other things it would have let you look at the actual values you were receiving, instead of just the characters they coded for.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also you can spend time to probe the TX/RX lines of the UART to see what is actually on the line.. you can verify all your claims in that...