FE in UART communication ?

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

Hi everyone.

Another tough story about serial transmission !

I'm using external Crystal 11.0592MHz and Fuse bits are correctly set.

 

UART setting on both side:

#define BAUD 9600
#include <util/setbaud.h>

void uart_init() {
	UART_UBRRH = UBRRH_VALUE;
	UART_UBRRL = UBRRL_VALUE;
	UART_UCSRB = (1 << UART_RXEN)|(1 << UART_TXEN)|(1 << UART_RXCIE)|(1 << UART_TXCIE);
#if USE_2X
	SET_BIT(UART_UCSRA, UART_U2X);
#endif
	// 8 bit + 1 stop bit + no parity
	UART_UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0);
}

Receive routine:

ISR(UART_RXC_INT) {
	Byte temp = UART_UCSRA;

	if (CHECK_BIT(temp, UART_FE)) {
		LED_ERROR();
		temp = UART_UDR; // dummy data
	} else {
		temp = UART_UDR;
		push_back(&buffer, &temp);
	}
}

Send routine:

ISR(UART_UDRE_INT) {
	if (buffer.count) {
		Byte temp;
		pop_front(&buffer, &temp);
		UART_UDR = temp;
	} else {
		CLEAR_BIT(UART_UCSRB, UART_UDRIE);
	}
}

What do you think ?

This topic has a solution.
Last Edited: Fri. Nov 3, 2017 - 05:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What do we think? About what? You've shown us some code, but not described a problem.

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

About Frame error(FE) as i put in the topic title !

 

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

What about FE? Are you getting framing errors on receive? How have you tested it? Let’s not play a guessing game here.

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

Are you getting framing errors on receive?

Yes

 Let’s not play a guessing game here.

Seriously !? 

How have you tested it?

Each time i receive a 10-bit char in RXC routine i check for UCSRA and if FE is set i Toggle a led to see that happened.

 

Last Edited: Thu. Nov 2, 2017 - 07:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

You’re not telling me much. Let me begin a list of unknowns:
What AVR?
What is CHECK_BIT?
What is UART_FE?
What is the source of the serial data?
How do you know it is correct?
How have you verified the hardware?

If you ignore the FE bit, do you get good data?
Yes, i am serious.

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

Your title is :

 

FE in software UART communication ?

 

 

This is not a software UART you use the hardware UART.

If you read it as a software UART you would expect that the FE is a byte (hex number for 253)

 

So 'seriously' be more clear!

 

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

iman4k wrote:
10-bit char 

Eh???

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

 

You are enabling the RXC and TXC interrupts, but the ISRs you provide are for the RXC and UDRE interrupts.  

Greg Muth

Portland, OR, US

Atmel Studio 7.0 on Windows 10

Xplained/Pro/Mini Boards mostly

 

 

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

sparrow2 wrote:
This is not a software UART 

+1

 

To be clear: 

 

"Software UART" is usually taken to mean that the UART function is implemented in software - by "bit-banging" aka "bit-bashing"

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

Tough crowd today...

 

iman,

I don't read C, so I can't check your code.

But a few thoughts:

 

Your Xtal freq and 9600 baud should be a good combination with 0% baud rate error, so good choice.

 

What is your actual hardware?

Two commercial boards?

Two breadboards?

Your own custom boards?

 

Do you have a common ground connection between the two micros?

 

Are you directly connecting the two micros' USARTs together, (TxD to RxD, RxD to TxD), or are you using an RS-232 or USB interface, etc?

 

Have you tried just sending 1 Byte at a time, say 1 Byte / second?

 

How are you displaying the received data, on an LCD, uploaded to a PC terminal, etc?

 

Do you have a O'scope to Logic Analyzer available to look at the signal actually transmitted?

 

How far apart are the two micros separated?

 

Do you have any Arduino type boards laying around, with which one could do some debugging on your current system?

 

JC

 

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

You seem to be asking "why am I getting framing errors with this code?"

But you have only shown us the content of the problem, but not the context of the problem!

Framing Errors occur when received data does not fit nicely within the frame of data expected, i.e. the stop bit detection did not detect a stop bit line level!

So, what could cause this?  cpu clock not as expected?  serial baud rate of the receiver is not the same as the baud rate setting of the transmitter?

 

It would help, if you would provide a small, complete program that demos the problem.  Show us your schematic, or picture of your setup.

Any additional context of how you are testing, what you have tried so far, etc.......

 

 

Jim

 

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

iman4k wrote:

Are you getting framing errors on receive?

Yes

How often?

 

  • occasionally?
  • frequently?
  • isolated events?
  • bursts?
  • all the time?

 

or what?

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

Lets try a bit of crystal ball gazing, here.

 

First, lets ask: What does a framing error represent? Answer: A framing error is generated when there is no stop bit in the expected location. 

 

Then, lets ask: How does this happen? There are several possible causes: (1) Noise on the transmission channel that makes it seem, to the receiver UART, that there is no stop bit; (2) Mismatched baud rate between the transmitter or the receiver - a data bit from the transmitter is being read by the receiver when it thinks there should be a stop bit; (3) Mismatch in the number of data bits between receiver and transmitter such that the transmitter sends a data bit during the time the receiver expects a stop bit; <edit> (4) transmit from a software UART that does not implement the stop bit correctly </edit>.

 

Now, iman4k (message #5) writes about "10-bit char". If you are using an AVR hardware UART, there is no way to send or receive a 10 bit character! There IS a 9-bit mode (interprocessor communications?) but no 10. If you have some external device that is sending 10-bit async characters, there is simply no way an AVR can deal with that. That 10th bit will fall exactly where the UART (in 9-bit mode) is expecting a stop bit. Bilngo - framing error. But, you have your UART set up for 8 bit, 1 stop, no parity. So, if you are really receiving 10 bit data, the 9th bit will fall where the stop bit should be, and bingo - framing error.

 

Is the crystal ball anywhere close? It really does not have to be this painful!

 

Jim

 

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Thu. Nov 2, 2017 - 10:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
Tough crowd today...

Agree completely. This board risks returning to the old days when apparently beginners were too scared to post because of the aggressive reception they might receive. The rule imposed at the time was simple - only post if you have something helpful to say.
.
Belittling beginners for the approach they happen to have chosen is not making this place friendly any more. To quote someone: "THINK!".

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

Just a guess, could the clock/8 fuse still be set?  Thus configuring the wrong baud rate setting.

Could you please post your fuse settings.

 

Jim

 

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

That could certainly lead to cause (2) that I described, above. It is certainly a bit sneaky in that the code would look good, but operation would be incorrect. 

 

I am putting my bet on (3), given the OP's comments about 10-bit data, also recognizing that some might call 8-bit data + start-bit + stop-bit as being "10-bit".

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Sorry. my mistake

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

Hi ka7ehk

Yes actually i meant 10-bit UART char as ->  [1 start bit + 8 data bit + 1 stop bit]

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

Thanks you all for helping on this.

 

Sorry for not telling more config and environment details.

I rechecked every thing from start and tried to narrow things down step by step, now the problem is solved.

 

My config was:

ATmega8A on two separate breadboards with individual power supply

11.0592MHz external crystal

Connection via TTL lines at close proximity.

9600 baud on both side.

 

But it seems the problem was with the power supply, i replaced individual PS (9V battery+7805) with a single USB power board for both.

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

DocJC wrote:

Do you have a common ground connection between the two micros?

Did you?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Now, yes they have common ground.

I didn't know that this is necessary for TTL connection between two avr

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The signal is reference to the Ground level, hence the need for the common connection. Good to hear you have it working.

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

 

iman4k -

 

We were not trying to be hard on you. I hope this exchange will help show why it is so important to include details. It is not always the code (though, often, of course, it is). A simple CKDIV8 fuse setting error, which would not appear in code, could have easily produced the symptoms you reported. 

 

Serial communications problems seem to be one of the most often recurring problems that are posted here. There are lots of similarities, of course, among them but there is a great variety of problems. I think yours is one of the first that I can recall, involving framing errors. 

 

This exchange also points to the importance of using standard terminology. Of course, this is especially difficult for beginners who may not have access to, or may not have stumbled across, such basic information. Calling it "10-bit data" threw most of us and proved to be a red herring. This is another reason for more details, because often those details help to clarify terms that may not be used correctly. We get a lot of this, also.

 

Power supply as a cause for this problem seems a bit strange. However, 9V battery and 7805 or 78L05 combination have become almost notorious for causing problems of all sorts. Glad that you have it working now. Hope your project progresses positively!

 

Cheers

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

iman4k wrote:
I didn't know that this is necessary for TTL connection between two avr

Not just TTL - It's needed for just about any connection!

 

Even the so-called "1-WireTM" connection is one wire plus ground!

 

The exception is when you have a differential connection.