Problem with serial baud rate.

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

I am trying to set up my first serial connection between an ATmega15L and my computer. I made a small program that constantly sends out data to the serial port to test and I am running into some problems I haven’t been able to solve. I loaded the UDR to 55h so the output frequency of Tx should be about equal the baud rate divided by two. When measuring the frequency with my DMM I get a frequency of 116.2kHz, which means the output baud rate is really 232400 when it should be 9600. I set the terminal baud rate to 232400 and the result is garbage data for an output.

I am using Bary’s terminal program (which I see everyone seems to recommend from searching for USART related topics :) )

Below is the source code I am using minus a few extras such as a delay routine and LED indicator functions.

;Frequency: 3.69Mhz

.include "m16def.inc"

.equ cbaud = 0d32 ;9600 baud

.def rmp = R16

.org 0x000
rjmp Reset

Reset: ldi rmp, high(ramend) ; Set up stack
out SPH, rmp
ldi rmp, low(ramend)
out SPL, rmp

ldi rmp, cbaud ; Baud rate setup
out UBRRL, rmp

ldi rmp, 0b00000000 ; UART setup
out UCSRA, rmp

ldi rmp, 0b00001000
out UCSRB, rmp

ldi rmp, 0b10000110
out UCSRC, rmp

rjmp TXcomp

Loop: sbis UCSRA, UDRE ; Wait for Tx complete
rjmp Loop

TXcomp:

ldi rmp, 0x55 ; Send this number to the serial port
out UDR, rmp

rjmp Loop

Thank in advance for any assistance you can offer me.

Will

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

1) check your fuses. The mega16 (I'm assuming you meant mega16 not 15) ships using the internal 1MHz oscillator.

2) for 3.69MHz (3.6864) The UBRR divisor should be 23, not 32.

3) for safety, you should load both UBRRH and UBRRL (though it's usually safe just to load UBRRL)

4) most PC uarts do not support speeds above 115K

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

1) Check

2) A type-o when I changed some things when I posted, the value in the asm file is 23.

3) Added UBRRH, no change.

4) Worth noting.

Nice avatar glitch, lol :)

Will

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

Quote:
When measuring the frequency with my DMM ...

I wouldn't trust that.

Do the fuse thing first to make sure you are REALLY running at the speed you think you are. Blink an LED at 1Hz or similar.

Your registers look OK to me, except for the aforementioned baud rate. what are you getting at the PC? Describe your circuit and RS232 converter.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I timed a one second delay and it seems to be a pretty accurate 1Hz

I probably should have given note of my hardware in my original post. I’m getting my clock from the STK500s programmable clock and I am also using the spare RS232 port on the STK500 as well. The cable should be working correctly because it is the same one I use to program the device.

Are there any settings on the terminal program I need to worry about other than the obvious Port#, baud, # of data bits, parity and stop bits? Handshaking set to “none” I presume?

Thank you for your help,

Will

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

wilbertone wrote:

... I am also using the spare RS232 port on the STK500 as well. The cable should be working correctly because it is the same one I use to program the device.
...

Did you install the jumpers to RS232 SPARE TXD/RXD from the correct PORTD header pins?

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Yep. I’m fairly sure the PC is getting a signal as at various baud rates I get information coming in. For example when 14400 baud is selected the terminal program displays 00h every 50+ byte transmissions (based on how fast the data appears) and at 28800 baud 00h is displayed at a much faster rate. Various other baud settings also give garbage data (not always 00h).

Will

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

I tested your code with a ATmega16 on a STK-500 using the 3.69 MHz software oscillator. I to say that I'm speechless is an understatment. I initially set the fuse for external oscillator 3 - 8 MHz and got the times baud rate time that wilbertone stated. I then added a pin toggle loop which should of taken 6 clocks but was taking only 4 clocks. I then took a careful look at the fuses and saw that it actually said external RC oscillator 3 - 8 MHz. Changed the fuses to external clock and voila Hyperterminal filled up with 'U's. Tried external crystal high frequency fuse and it still worked. Captured the XTAL1 line at the ATmega16 which is shown in the attached PNG file. Top trace is the external RC oscillator and bottom is the external clock.

Attachment(s): 

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

Well done! I wouldn't have thought of the clock fuses, as the consensus seems to be that if you are using the STK500-generated clock, you could set your AVR fuses to just about any old setting.

Some type of an overtone or something inside the AVR when the RC fuse is selected?

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Now that I slept on the problem I tried some other stuff. I was wrong about the pin toggling. It should of toggled at 3.2 us but it was toggling 1.08 us. Remeasured the UART bit time and it was 34 us instead of 104 us for 9600 bps. The ATmega16 is running at 3 time the 3.69 MHz oscillator. Calculated the baud rate for 11.07 MHz (UBRR = 71) and Hyperterminal filled up with 'U's.

The wierd clock only shows up when external RC osc. 3 - 8 MHz or external RC 8 - 12 MHz fuse is selected. When the two slower external RC osc. were selected, I measured 3.69 MHz on XT1 but the falling edge had a little glitch at about 0.5 V to ground.

I never thought about the fuse setting being critical on the STK-500. I would of normally selected the external crystal fuse but I guess I was just too tired to see the RC in external RC oscillator.

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

I checked my fuse settings and they all seem to be what I want them to be. The clock setting is on the Ext Clock mode. I have also tired using the external Xtal setting.

I threw PBar’s UBRR value in for kicks and found an oddly familiar value on my DMM. After changing the UBRR from is minimum value to max value and changing the chip I am always getting 116.2kHz reading on my DMM from the Tx pin. Now, I suspect that even if my frequency was inaccurate, I should be at least getting a different frequency value for different UBRR settings. Currently it seems my UART is stuck at a constant baud rate regardless of which chip and UBRR value I use.

I will have access to an oscilloscope Monday and I will take a more accurate look at the signals than.

Thanks offering me your help.

Will

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

Quote:
Now, I suspect that even if my frequency was inaccurate, I should be at least getting a different frequency value for different UBRR settings. Currently it seems my UART is stuck at a constant baud rate regardless of which chip and UBRR value I use.

Most likely your DMM isn't measuring it properly - they are designed normally for only square waves or other symmetrical waveforms - if your TX output isn't that then it might not be accurate at all.

Regards,

-Colin

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

Colin,

I am measuring the Tx output on the microcontroller pin, which is is a square wave.

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

I tried some other external crystals (6 MHz, 8 MHz, 12 MHz) and never could the UART TXD pin to be above 20 kHz. Then I set cbaud to 0 and voila, 116 kHz. Here's my test code if you care.

;Frequency: 3.69Mhz 

.include "m16def.inc" 

.equ cbaud = 0 ;9600 baud 
;.equ PA0_TOGGLE		= 0

.def rmp = R16 

.org 0x000 
	rjmp	Reset 

Reset: 
	ldi	rmp, high(ramend) ; Set up stack 
	out	SPH, rmp 
	ldi	rmp, low(ramend) 
	out	SPL, rmp 

	ldi	rmp,HIGH(cbaud)
	out	UBRRH,rmp
	ldi	rmp,LOW(cbaud) ; Baud rate setup 
	out	UBRRL, rmp 

	ldi	rmp, 0b00000000 ; UART setup 
	out	UCSRA, rmp 

	ldi	rmp, 0b00001000 
	out	UCSRB, rmp 

	ldi	rmp, 0b10000110 
	out	UCSRC, rmp 

	sbi	DDRA,0  ; use PA0 as pin toggle output

	rjmp	TXcomp 

Loop:	sbis	UCSRA, UDRE  ; Wait for Tx complete 
	rjmp	Loop 
TXcomp: 
	ldi	rmp,0x55	; Send this number to the serial port 
	out	UDR, rmp 

.IFNDEF PA0_TOGGLE
	rjmp Loop 
.ELSE
	ldi	rmp,200	; pin test loop 
	ldi	R18,(1<<0)	; bit constant to toggle bit 0
PinToggle:
	in	R17,PORTA	; get current PORTA latches
	eor	R17,R18	; toggle bit 0
	out	PORTA,R17	; write new settings
	dec	rmp	; one less pin toggle loop
	brne	PinToggle	; loop until 0

	rjmp Loop 
.ENDIF
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, I threw your code into the assembler and tested it. I am now reading the correct values on the terminal program and correct baud frequency. So, it works. Now all I have to do is find out why. The most obvious difference is in the way you set up UBRRH and UBRRL registers. Perhaps that was it as writing zero for the UBRR produces the same frequency I was getting.

I should probably remember to set all 16 bit registers that way.

Thank you very much for your help, I truly appreciate it.

Will

PS, which program are you using to assemble it? I’m currently using AVR Studio, which does not support some of the very useful assembler directives you used.

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

You are welcome. I learned several things working on this project.

I'm using AVRStudio 4.10.356. I have enabled AVR Assember 2 but I don't think there is anything special to that version. Are you talking about the conditional assembly directives? That got added with the assembler included with AVRStudio version 4.08. I had been waiting a long time for that and wore out the semicolon key on two keyboards. :oops:

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

Ahh, that would be it, I'm currently with v3 of AVR Studio.

Maybe I can save my semicolon key before it's too late by switching. heh

Regards,

Will