STK500/525, Serial issue

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

Hello,

I am running a simple loopback in preparation for doing some more complicated things over serial.

My Setup is a 90USB1287, in a STK525 on a STK500. This is then connected to a FT232R, and then my PC which is using hyperterminal.

Everything is working as expected, with one big catch. when I tx from hyper terminal this is what I get.

pls see attachment

As you can see the voltage is approx. between 1.5-3.3v instead of 0-3.3 as I expect it to be.

Thanks in advance.

Attachment(s): 

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

Quote:

As you can see the voltage is approx. between 1.5-3.3v instead of 0-3.3 as I expect it to be.

Which suggests that maybe a common ground is not being used?

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

I had set some grounds but it wasn't ideal so i re-grounded everything and this is what I get. (basically no change but much less noise.)

Attachment(s): 

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

This is what the tx coming out of the ft232r looks like when not connected to the uC.

Attachment(s): 

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

I tried a new tack. I set up the portd as inputs and tried tx'ing to it. I got the same result does this mean my uC is fried?

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

Looks like the MCU (or something else) is pulling the line high, anything else connected? Could you post the initialisation routines, and possibly a simple schematic?

If you suspect the MCU to be fried, try communicating with it trough ISP. Then make a simple LED-blinker, maybe even using the same pin as the tx-line is on to check that output. If all that works, then no, your MCU is not fried.

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

I made a light show and I always change the initial transmit so that I can see something new in hyperterm to make sure the new program got loaded properly.

Here is the code and a basic schematic. I have an LCD setup on portA and C (data and com respectively) but the are not initialized.

Also when I try just doing a loopback (on the uC) the signal is ok but I still don't trigger the rx routine.

#define F_CPU 8000000UL //8MEG

#include 
#include 
#include 
#include 
// Define baud rate

#define USART_BAUD 9600ul
//#define USART_UBBR_VALUE ((F_CPU/(USART_BAUD<<4))-1)
#define USART_UBBR_VALUE ((F_CPU / (USART_BAUD * 16UL))-1)
/*
ISR(USART_RXC1_vect) 
{ 
	char byte1;
    byte1 = UDR1;
    _delay_ms(250);
    UDR1 = byte1;
}
*/
void USART_vInit(void)
{
	// Set baud rate
	UBRR1H = (uint8_t)(USART_UBBR_VALUE>>8);
	UBRR1L = (uint8_t)USART_UBBR_VALUE;
	// Set frame format to 8 data bits, no parity, 1 stop bit
	UCSR1C = (0<<USBS1)|(1<<UCSZ11)|(1<<UCSZ10);
	// Enable receiver and transmitter
	UCSR1B = (1<<RXEN1)|(1<<TXEN1);
	//UCSR1B |= (1 << RXCIE1);

}
void USART_vSendByte(uint8_t u8Data)
{
	// Wait if a byte is being transmitted
	while((UCSR1A&(1<<UDRE1)) == 0);
	// Transmit data
	UDR1 = u8Data;
}

uint8_t USART_vReceiveByte()
{
	char byterxd;
	// Wait until a byte has been received
	while((UCSR1A & (1<<RXC1)) == 0);
	// Return received data
	byterxd = UDR1;	
	return byterxd;
}
int main(void)
{
	uint8_t u8Data;
	// Light show
	DDRB = 0xff;	
	PORTB = 0xFF;
	_delay_ms(250);
	PORTB = 0x00;
	_delay_ms(210);
	PORTB = 0xF0;
	_delay_ms(210);
	PORTB = 0x0F;
	_delay_ms(210);
	PORTB = 0x00;

	USART_vInit();
	// Send string
	USART_vSendByte('0');
	
	while(1)// Repeat indefinitely
	{
		// Echo received characters
		u8Data = USART_vReceiveByte();
		_delay_ms(10);
		USART_vSendByte(u8Data);
		PORTB ^= 0xAA; //never gets here :'(
	}

}

Attachment(s): 

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

Ok so if anyone cares, I don't know what is wrong with it but it was the ft232. I replaced it by using a of the shelf usb-serial and hooked that to the onboard serial and it works now.

Still one catch (of course) I can see the uC getting the signal and spitting it immediately back out but realTerm doesn't see it. Even though it sees the initial message which is sent using the same subroutine.

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

Hi again, sorry for a late reply.

Glad you got the hardware part figured out, I have no idea why the data dont show up on your computer, so someone else have to comment on that.

One thing I notice is that you have a delay_ms() inside the interrupt routine, remove that and use the interrupt to set a flag that the main code handles. Something like:


ISR(USART_TX1_vect)
{
    Flags |= DATA_RECEIVED
}

main()
{
    if((Flags & DATA_RECEIVED) == DATA_RECEIVED)
    {
        // Insert code to handle the data
    }
} 

Not that it matters much now as the global interrupt is disabled tough.

Try to make a program which is as simple as possible to verify that the uC->PC connections is working. Should be an example in the tutorials section in this forum. Might be easier to simply wire the RX and TX from the ft232 together and sending data from the terminal.

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

Yes that's always a good idea, I actually had the interrupt commented out at the time and was just polling. But now I am trying to get it working and am having more troubles.

Currently when I trigger the interrupt I get into a reset loop. I figure I must have my vector written wrong but I can't find it in the data sheet.

I have tried these;

ISR(USART1_RXC_vect) 
{ 
	cli();
	PORTB ^= 0xC3; //flash some debugging led's
	rxflag = 0x01;
	sei();
	reti();
}
ISR(USART_RXC1_vect)
ISR(USART_RXC_vect)

all no dice.

here is my main as it stands;

int main(void)
{
	 
	char charData;	
	uint8_t rtn;
	rxflag = 0x00;		

	// Light show
	DDRB = 0xff;	
	PORTB = 0xFF;
	_delay_ms(250);
	PORTB = 0x00;

	USART_vInit();
	// Send string
	USART_vSendByte('0'); //I change this to verify programming

	SendStringtoUSARTpm(txString);
	
	sei();

	while(1)
	{
             // Repeat indefinitely
	}

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

Quote:

I have tried these

Don't guess. They are:

E:\WinAVR-20100110\avr\include\avr>grep _vect iousbxx6_7.h
#define INT0_vect                       _VECTOR(1)
#define INT1_vect                       _VECTOR(2)
#define INT2_vect                       _VECTOR(3)
#define INT3_vect                       _VECTOR(4)
#define INT4_vect                       _VECTOR(5)
#define INT5_vect                       _VECTOR(6)
#define INT6_vect                       _VECTOR(7)
#define INT7_vect                       _VECTOR(8)
#define PCINT0_vect                     _VECTOR(9)
#define USB_GEN_vect                    _VECTOR(10)
#define USB_COM_vect                    _VECTOR(11)
#define WDT_vect                        _VECTOR(12)
#define TIMER2_COMPA_vect               _VECTOR(13)
#define TIMER2_COMPB_vect               _VECTOR(14)
#define TIMER2_OVF_vect                 _VECTOR(15)
#define TIMER1_CAPT_vect                _VECTOR(16)
#define TIMER1_COMPA_vect               _VECTOR(17)
#define TIMER1_COMPB_vect               _VECTOR(18)
#define TIMER1_COMPC_vect               _VECTOR(19)
#define TIMER1_OVF_vect                 _VECTOR(20)
#define TIMER0_COMPA_vect               _VECTOR(21)
#define TIMER0_COMPB_vect               _VECTOR(22)
#define TIMER0_OVF_vect                 _VECTOR(23)
#define SPI_STC_vect                    _VECTOR(24)
#define USART1_RX_vect                  _VECTOR(25)
#define USART1_UDRE_vect                _VECTOR(26)
#define USART1_TX_vect                  _VECTOR(27)
#define ANALOG_COMP_vect                _VECTOR(28)
#define ADC_vect                        _VECTOR(29)
#define EE_READY_vect                   _VECTOR(30)
#define TIMER3_CAPT_vect                _VECTOR(31)
#define TIMER3_COMPA_vect               _VECTOR(32)
#define TIMER3_COMPB_vect               _VECTOR(33)
#define TIMER3_COMPC_vect               _VECTOR(34)
#define TIMER3_OVF_vect                 _VECTOR(35)
#define TWI_vect                        _VECTOR(36)
#define SPM_READY_vect                  _VECTOR(37)

I don't see a "C" in "RXC"

(in theory these vector names are named exactly as given in the datasheet - if this is not the case this should be raised as an error against AVR-LibC).

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

Thanks I was looking through the includes but control f with RXC failed since as you said the C is gone. In the data a sheet it is listed in the table as USART RX but I am new to interrupts so I didn't realize that was literally the name. Thanks

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

Ok new problem!

I can get into the ISR now but I can never leave.

Does anyone see anything glaringly wrong?

#define F_CPU 8000000UL //8MEG

#include 
#include 
#include 
#include 
#include 
#include 

// Define baud rate

#define USART_BAUD 9600ul
#define USART_UBBR_VALUE ((F_CPU / (USART_BAUD * 16UL))-1)

#define STR1 "I just changed this string!"
#define STR2 "This isn't working right/0"

char  rxflag;
const uint8_t txString[] PROGMEM="A quick brown fox jumps over the lazy dog!/0";
char  rxString[63] = STR2;	

ISR(USART1_RX_vect) //aka hotel california
{
	cli();
	rxflag = 0x01;
	PORTB = 0x55; //debug LEDs
	reti();
	//strcpy(rxString, STR1); 
}

void USART_vInit(void)
{
	// Set baud rate
	UBRR1H = (uint8_t)(USART_UBBR_VALUE>>8);
	UBRR1L = (uint8_t)USART_UBBR_VALUE;
	// Set frame format to 8 data bits, no parity, 1 stop bit
	UCSR1C = (0<<USBS1)|(1<<UCSZ11)|(1<<UCSZ10);
	// Enable receiver and transmitterg
	UCSR1B = (1<<RXEN1)|(1<<TXEN1);
	UCSR1B |= (1 << RXCIE1);

}
void USART_vSendByte(char u8Data)
{
	// Wait if a byte is being transmitted
	while((UCSR1A&(1<<UDRE1)) == 0);
	// Transmit data
	UDR1 = u8Data;
}



void SendStringtoUSARTpm(const uint8_t *FlashLoc)
{
	uint8_t i;
	for(i=0;(uint8_t)pgm_read_byte(&FlashLoc[i]);i++)
	{
		USART_vSendByte((uint8_t)pgm_read_byte(&FlashLoc[i]));
	}
}

void SendStringtoUSART(char str[])
{
	uint8_t i;
	uint8_t len;
	len = strlen(str);
	for(i=0;i
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You don`t want cli() and reti() inside the interrupt, the compiler will sort that out itself.

A very quick look also tells me that the "rxflag" variable is not declared "volatile", that is a must to tell the compiler that this value may change at any time, also outside the main loop.

I got another advice for you, try to make the interrupt working first, then all the other stuff. It just makes everything harder to debug when there is a lot potential flaws. Here, I modified your code to give you a simple starting point: I do not guarantee that it is working, so if it does not work on first go, feel free to scrap it. The comments should make the program pretty much self explaining too :)

#define F_CPU 8000000UL //8MEG

#include 
#include 
#include 
#include 
#include 
#include 

// Define baud rate

#define USART_BAUD 9600ul
#define USART_UBBR_VALUE ((F_CPU / (USART_BAUD * 16UL))-1)

volatile uint8_t rxflag = 0;
volatile char temp;

ISR(USART1_RX_vect) //aka hotel california
{
   rxflag = 0x01;
   temp = UDR1; // Save character to a temporary place
   UDR1 = temp; // Echo back the same character
}

void USART_vInit(void)
{
   // Set baud rate
   UBRR1H = (uint8_t)(USART_UBBR_VALUE>>8);
   UBRR1L = (uint8_t)USART_UBBR_VALUE;
   // Set frame format to 8 data bits, no parity, 1 stop bit
   UCSR1C = (0<<USBS1)|(1<<UCSZ11)|(1<<UCSZ10);
   // Enable receiver and transmitterg
   UCSR1B = (1<<RXEN1)|(1<<TXEN1);
   UCSR1B |= (1 << RXCIE1);

}


int main(void)
{
	DDRB = 0xff;
	PORTB = 0x55;

	sei();

	while(1)// Repeat indefinitely
	{   
		if(rxflag == 0x01) // Have I received data?
		{  
			if(temp == 'a') // Is is it the character 'a'???
			{
				PORTB++; // If so, increment PORTB.
			}			 
			else
			{
				PORTB ^= PORTB;   // If character is not 'a', invert PORTB bits. 	
			}
			rxflag = 0x00;   
			//eventually will have rx code here.
		}
	}
}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was able to make progress with making my flag volatile but when it goes into the isr the timing gets all slow. something that should be immediate is taking over a minute and then it doesn't go back to my loop (blinky LED's)

ps thanks!