USART Interrupt Keeps Firing with No Data Input on RXCIF Flag

Log in or register to post comments
Go To Last Post
16 posts / 0 new
Author
Message
tdvdesign
tdvdesign's picture
Level: New Member
Joined: Wed. Aug 1, 2018
Posts: 13 View posts
#1
Posted by tdvdesign: Tue. Jan 7, 2020 - 03:23 PM
  • 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

Tags:

AVR Microcontrollers, AVR and XMEGA
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101079 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Jan 7, 2020 - 03:30 PM
  • 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
Top
tdvdesign
tdvdesign's picture
Level: New Member
Joined: Wed. Aug 1, 2018
Posts: 13 View posts
Posted by tdvdesign: Tue. Jan 7, 2020 - 03:31 PM (Reply to #2)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My apologies, ATTINY1604 with Atmel Studio.

Regards,
Tom

Top
tdvdesign
tdvdesign's picture
Level: New Member
Joined: Wed. Aug 1, 2018
Posts: 13 View posts
Posted by tdvdesign: Tue. Jan 7, 2020 - 03:40 PM (Reply to #3)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Thank you,
Tom

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101079 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Jan 7, 2020 - 03:43 PM
  • 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
Top
tdvdesign
tdvdesign's picture
Level: New Member
Joined: Wed. Aug 1, 2018
Posts: 13 View posts
Posted by tdvdesign: Tue. Jan 7, 2020 - 03:54 PM (Reply to #5)
  • 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

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101079 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Jan 7, 2020 - 04:12 PM
  • 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"?

Top
DocJC
DocJC's picture
Level: 10k+ Postman
Joined: Tue. Dec 11, 2007
Posts: 13284 View posts
Location: Cleveland, OH
Posted by DocJC: Tue. Jan 7, 2020 - 04:18 PM
  • 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

Top
tdvdesign
tdvdesign's picture
Level: New Member
Joined: Wed. Aug 1, 2018
Posts: 13 View posts
Posted by tdvdesign: Tue. Jan 7, 2020 - 04:24 PM (Reply to #8)
  • 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

Top
DocJC
DocJC's picture
Level: 10k+ Postman
Joined: Tue. Dec 11, 2007
Posts: 13284 View posts
Location: Cleveland, OH
Posted by DocJC: Tue. Jan 7, 2020 - 05:04 PM
  • 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

 

Top
tdvdesign
tdvdesign's picture
Level: New Member
Joined: Wed. Aug 1, 2018
Posts: 13 View posts
Posted by tdvdesign: Tue. Jan 7, 2020 - 05:17 PM (Reply to #10)
  • 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

Top
jgmdesign
jgmdesign's picture
Level: Moderator
Joined: Mon. Mar 19, 2007
Posts: 17732 View posts
Location: Long Island New York
Posted by jgmdesign: Tue. Jan 7, 2020 - 05:54 PM
  • 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

Top
Kartman
Kartman's picture
Level: 10k+ Postman
Joined: Thu. Dec 30, 2004
Posts: 24773 View posts
Location: Melbourne,Australia
Posted by Kartman: Tue. Jan 7, 2020 - 10:03 PM
  • 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.

Top
Chuck99
Chuck99's picture
Level: Posting Freak
Joined: Sat. Oct 31, 2009
Posts: 1474 View posts
Location: Vancouver, WA, USA
Posted by Chuck99: Tue. Jan 7, 2020 - 10:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Top
Simonetta
Simonetta's picture
Level: Raving Lunatic
Joined: Wed. Mar 12, 2003
Posts: 3021 View posts
Location: Portland, Oregon USA
Posted by Simonetta: Tue. Jan 7, 2020 - 11:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try NOT reading usart0. RXDATAH.

 

 

 

 

 

 

 

 

DATAH

Top
ki0bk
ki0bk's picture
Level: Raving Lunatic
Joined: Mon. Sep 8, 2014
Posts: 8395 View posts
Location: Olathe KS
Posted by ki0bk: Wed. Jan 8, 2020 - 12:03 AM
  • 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

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

Top