STK500 8515 UART USART frustrations

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

Ok..., for *three* days I've been trying to get Vista, WinAVR, AVR Studio, and an STK500 to cooperate. I'm a total noob, but about to throw in the towel. Assembly via Studio works fine. Trying to get a dumb serial routine to work via Winavr is going nowhere.Code is attached. Compiles with no errors, runs in Debug simulator fine..., I can watch PORTD bit 1 (UART Tx) changing at the proper rate. Sending a non-stop string of 'U's toggles the output nicely. BUT.., when downloaded to the STK500/8515...,no output. The PORTD outs are OK.., as I can download a blinky program that works fine, the Max 232 circuit is fine and jumpered to PD0/PD1...., there's just nothing being produced by the chip. What am I missing?

TIA,
John

Attachment(s): 

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

What has got me a few times is that the file to download has to be selected by you,it is not done automatically when you change projects. Just one of those things that can bite you.

Pete

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

Your code:

#define BIT(n) (1 << (n))

void setup_uart(void)
{
	UBRR = 23;
	UCSRB |= BIT(TXEN);
	return;
}

void send_character (unsigned char c)
{
	while ( (UCSRA & BIT (UDRE) ) == 0 ); // Something looks amiss here.  Check my code below.
	UDR = c;
	while ( (UCSRA & BIT (TXC) ) == 0); // This isn't needed, as you check UDRE this upon entry - which is the correct place to check.
}

int main(void)
{
	setup_uart();
	while (1){
	 send_character('U');
	}	 
}

My code:

// ImageCraft ICC-AVR C compiler V7.xx
// Target micro-controller: Mega32
// Crystal: 16.0000Mhz

#include 
#include 

// UART0 initialize
// Desired baud rate = 9600
// Actual baud rate = 9615
// % Error = 100 - ((9600 / 9615) * 100) =  0.156%
// No Parity, 8 bits, 1 Stop bit: (N-8-1)
void uart0_init(void) {
     UCSRB = NULL; // Disable while setting baud rate
     UCSRA = NULL;
     UCSRC = (1<<URSEL) | (1<<UCSZ1) | (1<<UCSZ0); // Select 8 bit data
     UBRR = 0x0067; // Set baud rate lo: 9600 BAUD
     UCSRB = (1<<TXEN); // Enable USART transmitter
}

/* Using the ImageCraft ICC-AVR compiler, putchar()
   must be defined be the user.  This allows the
   user to use all of the features of stdio.h and
   select the USART or other output hardware, such
   as an HD44780 text based LCD display.
*/
void putchar(char c) {
     // Wait for empty transmit buffer
     while ( !(UCSRA & (1<<UDRE)) ) // Note the way '!' UDRE is checked...               
     ;
     UDR = c; // Putting data into buffer , sends the data
}

void main(void) {
     uart0_init();

     while(1) printf("Hello world!\n");
}

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

digitool wrote:
What has got me a few times is that the file to download has to be selected by you,it is not done automatically when you change projects. Just one of those things that can bite you.

Pete

Thanks Pete, but I'm actually transferring the hex file to another computer and using AVR Studio (also on that machine) to program the 8515, so I know the right file is being used. I should add here that frequency specification (3684000), chip specification are both correct, and the program verifies OK.

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

Quote:

void send_character (unsigned char c)
{
while ( (UCSRA & BIT (UDRE) ) == 0 ); // Something looks amiss here. Check my code below.
UDR = c;
while ( (UCSRA & BIT (TXC) ) == 0); // This isn't needed, as you check UDRE this upon entry - which is the correct place to check.
}

Carl,
Thanks for the comments..., the bit tests are equivalent..., I think.., as for testing the TXC bit. you're right, probably not necessary, but the code runs the same same with it or without it..., just a tad slower. I'm flummuxed..., this seems such a silly little task. I'm 95% certain it's not a code problem, per se, but something to do with my usage of the tools. Most of all, I can't figure out why the debugger simultor works fine, but the real thing doesn't. I'm certain (?) that CPU specification and frequency are right....

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

First, I'm surprised that your code compiles with winavr/avr-gcc. I don't believe UBRR is defined. At least I get an error using winavr-20070525. Changing it to UBRRL works ok.

Also, if you are using the clock generated on the stk500, make sure that the avr's fuse bits are set for external clock...I think the 8515 that comes with the stk500 is ok, but by default they use the internal oscillator.

Finally, make sure that the RS232 SPARE connector on the stk500 is connected properly and your pc is connected to the RS232 SPARE db9.

I hope this is helpful.

-wolfy

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

Quote:

First, I'm surprised that your code compiles with winavr/avr-gcc. I don't believe UBRR is defined. At least I get an error using winavr-20070525. Changing it to UBRRL works ok.

Wolfy,
Thanks for the reply. You're right about the UBRR/UBRRL defines, I altered iom8515 to take care of that. Perhaps not wise, but convenient.

Quote:

Finally, make sure that the RS232 SPARE connector on the stk500 is connected properly and your pc is connected to the RS232 SPARE db9.

Yes,and I've verified via 'scope that no signal being generated on PORTD pin1.

I'm concerned that the FUSES may not be set correctly, having a dickens of time trying to find precise information about them and default STK500 settings, and STK500 clock options. Let me be clear, I'm running the STK500 as it came out of the box. No crystal added, or external clock selected.
And now..., blinky.asm will no longer program.., I get a failure to program message..., thus my suspicion that I have a fuse problem. Something funny going on, and I'm practically at a loss.

John

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

Keep in mind there is one other avenue than switching machines. Simply find the .exe for avr studio and right click on it, go to properties, and there should be a tab labeled compatibility. select windows XP. The problem has gone away on me a few times.

Jim.

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Jim,
The reason I switch machines is to get to an RS-232 port (on an old laptop)...., sure *wish* that I could just push a button and make one appear on this machine. Just haven't picked one up yet...

John

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

Oh yeah...., got my blinkie.asm going again, so at least the chip seems OK. Also switched to HV programming..., whereupon I realized that the chip is a AT90S8515.., NOT Atmega8515 ....., so fuses are not the problem. I remain befuddled..
John

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

John,
I missed that you needed the rs232 - My Bad

Just choose AT90S8515 in AVRStudio and program the chip with ISP. Should work. Also make sure the fuses are set to accomodate ISP first as you would need to set them with the parallel programmerr.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

I wonder if being the older chip that it is, the output pin would not be set as an output pin automatically when starting up the uart module.

Pete

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

The output is set automatically when the TXEN bit is set in the UCR register ( read the datasheet would you Pete).

Tried a little program on my STK500 and it works OK.


.include  "8515def.inc"

.def	Temp	=r16
.def	Delay	=r17
.def	Delay2	=r18
.org	$000
rjmp	RESET

RESET:
ldi	r16,high(RAMEND)
out	SPH,r16	
ldi	r16,low(RAMEND)
out	SPL,r16

START:

rcall RS232INIT

LOOP:

T1:
;uncomment delays for slower output
;with delays commented output is square wave-fills buffer fast
;rcall 	dly 
;rcall 	dly



ldi	r16,'U'		;character to produce square wave
rcall 	RS232OUT
rjmp 	LOOP


RS232INIT:


ldi	r16,23 		;set for 9600 baud using STK500 clock
out	UBRR,r16
ldi	r16,1<<txen	;enable trnsmit on PD1
out 	ucr,r16

ret

RS232OUT:


sbis	USR,UDRE	;test transmit ready
rjmp 	RS232OUT

out	UDR,r16		;send character
ret

DLY:

dec	Delay
brne	DLY
dec	Delay2
brne	DLY

ret

Pete

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

RESOLVED!!

First of all..., THANKS to all of you for taking the time & effort to respond to my problem. Actually, there were many problems that I worked my way through..., including getting Winavr to run under Win98, for the machine that has a 232 port. Ultimately I switched to this Vista machine with no 232, so I had to shuffle files back and forth.
Then there was the problem with UBRR not being defined...., then there was a problem with AVR Studio and specifing Atmega8151 vs. AT90S8515, which led to fuse weirdness. THEN there was the REAL problem.. Operator Ignorance. For some robot-like reason, I insisted on pushing the AVR "Read" button under the "Input HEX file" field every time I downloaded a new hex file to the 232 machine....., thereby reading the (bad)flash *back* into the hex file. I hear that humility is good for the soul.., well probably, but the process sure can lead to gray hair.
At any rate, I'm now blinking and sending characters, so, again, many, many thanks to you all. What a great forum...
John