USART Interrupt Keeps Firing with No Data Input on RXCIF Flag

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

Hi,

My USART interrupt continuously trips on the RXCIF flag even though there is no data line connected.  I am reading both RXDATAL and RXDATAH in the interrupt to reset the flag each time (confirmed that the flag is reset), but it just trips again.

Interrupt:

// Interrupt vector for USART RX
ISR(USART0_RXC_vect)
{
	// Store character received
	uint8_t tempCharH = USART0.RXDATAH;
	uint8_t tempChar =  USART0.RXDATAL;
	
	// Counting int
	uint8_t i = 0;
	
	// If char is start of a command...
	if(tempChar == '$')
	{
		// Reset position to zero in buffer
		strPosition = ctrlString;
		
		// Clear buffer
		for (i = 0; i < CTRL_LEN; i++ )
		{
			ctrlString[i] = 0;
		}
	}
	// If char is end of a command '!'...
	if(tempChar == '!')
	{
		// Set command flag
		isCommand = TRUE;
	}
	
	// Write character to buffer
	*strPosition = tempChar;

	// Shift position
	strPosition++;
}

 

Initialization:

// Initialize USART comms
void USART_Init()
{
	// Set RX pin to input
	PORTA.DIRCLR = PIN2_bm;
	// Set BAUD rate
	USART0.BAUD = BAUD_REGISTER;
	// Set receive complete flag
	USART0.CTRLA = USART_RXCIE_bm;
	// Turn on RX hardware
	USART0.CTRLB = USART_RXEN_bm;
}

 

Thank you,
Tom

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

You might want to say which model of AVR this is. I see from other posts you mention tiny817??

 

Tiny817 is an "AVr-1" (the datasheet says) so I guess this is what is colloquially known as "Xtiny" so maybe your post in the "Xmega" forum is not too wide of the mark ??

Last Edited: Tue. Jan 7, 2020 - 03:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My apologies, ATTINY1604 with Atmel Studio.

Regards,
Tom

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

Can I move a post, or just repost in the correct forum?

Thank you,
Tom

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

OK so I guess that makes it an "AVR-0" in fact. That is still "Xtiny" so I guess this Xmega forum is as close as anything - it's certainly not something that would fit into the "Mega/Tiny" forum despite the misleading ATTiny1604" name !

 

One thing that makes Xmega (and now AVR-0/AVR-1, "XTiny") different to traditional Tiny/Mega is that they don't do as much about "auto-clearing" interrupt flag sources. In traditional tiny/mega the very act of vectoring to an ISR handler was enough to clear most interrupt flag sources but in Xmega (and now all these new derivatives) there's usually more positive action required to clear interrupt flags.

 

What does the 1604 datasheet say about the RXCIF and how it should be cleared?

 

EDIT: answering my own question:

When interrupt-driven data reception is used, the receive complete interrupt routine must read the received data from RXDATA in order to clear the RXCIF. If not, a new interrupt will occur directly after the return from the current interrupt.

Last Edited: Tue. Jan 7, 2020 - 03:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

From the datasheet:

When interrupt-driven data reception is used, the receive complete interrupt routine must read the received data from RXDATA in order to clear the RXCIF. If not, a new interrupt will occur directly after the return from the current interrupt.

 

In the code, I do this (uint8_t tempChar =  USART0.RXDATAL;), and can see by debugging that it is indeed clearing the flag.  However, the flag turns back on somehow and re-enters the interrupt.  The RX input is not physically attached to any source to receive data, so I am not sure what is turning the RXCIF flag on. 

 

I am, however also getting a FERR frame error bit on, and I am not sure what is causing that either.

Regards,

Tom

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

So it could be as simple as a clock/baud issue.

 

Remember that most of these new chips now seem to default to a 20MHz / 6 clock so how are you calculating "BAUD_REGISTER"?

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

Is the RxData line floating, ie not connected to anything?

 

If so it can generate random garbage data.

 

At least for now, while you are working without a true serial source connected, just tie the RxData line low with a resistor, (anything from 330 ohms to 10K ohms would be fine).

 

JC

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

Doc,

It is connected to an RS485 transceiver that is set up for RX only.  The unit will have times when it is disconnected from an RS485 input source, so I should probably just reject the garbage data?  I am not sure how it will behave with the pulldown and the RS485 setup.

 

Clawson,

The BAUD_REGISTER is calculated with the following:

 

// Define clock speed
#define F_CPU 20000000UL
#define F_PER 3333333UL				// 20mHz CPU clock divided by standard MCLKCTRLB #b00010001 is 6 = 3333333.33 Ticks/s
// Define UART items
#define USART_S	16L					// S factor in normal asynchronous mode
#define USART_BAUDRATE 9600L
#define BAUD_REGISTER ((64 * F_PER) / (USART_S * USART_BAUDRATE))

Thank you,
Tom

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

Yes, as is usually the case, it isn't the trivial solution you are looking for...

 

Disclaimer:  I have very little experience with RS-485.

 

That said, perhaps some experts will be along shortly.

 

And that said, does your node have a biasing network / termination resistor setup connected to the two signal lines?

 

I still think you need to hold the lines in a known state when the node is disconnected from the rest of the network, it is just that a single pull-up or pull-down resistor won't do the trick.

For RS-485 I think one might use a biasing network with three resistors in series, connected from V+ to Ground, with the two central connections going to the two signal lines.

(Tough to describe with words..., unless you are already familiar with the item being described.)

 

The upper and lower resistors might be ~ 720 ohms, the middle resistor ~ 130 ohms.

 

This will hold the signal lines in a known state so that noise / floating lines don't generate and endless stream of garbage data.

 

Eliminating the garbage data in software is doable, but not desirable.

Your micro will bombarded with a continuous stream of bogus data to sort through.

Although your system will likely need to be able to detect valid data vs (occasional) bogus data in software, you really want the hardware to minimize the bogus data's generation from the open ended input to begin with.

 

JC

 

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

Hi,

I am not sure if it is relevant, but the 'garbage' data is always null.  The FERR frame error and RXCIF are always on, but there is no actual data there.  I have worked with other processors with the same MAX485 setup, and not had a garbage data issue.  I am wondering if it is something else.

Regards,
Tom

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

Put a pull up resistor on the RXD line to Vcc.  Works every time. 

 

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

Real MAX485s give an idle condition with an undriven bus. Other chips like the classic 75176 give you a break condition. The break condition generates a null. If you are getting lots of nulls, then there is noise causing transitions. Or maybe the break detection is a design feature of the chip.

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

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

Try NOT reading usart0. RXDATAH.

 

 

 

 

 

 

 

 

DATAH

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

Most 485 xcvrs I have worked with require a pull up resistor on the rxd line, 10k usually works well.

serial lines idle high, so if the rxd line floats when not selected, this will cause noise to trigger framing errors.

jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...