Serial Framing Error

syndetic1 · Joined: 02 Jan 2007 Posts: 80

hi guys,
I am using a ATMEGA128. This has two UARTS and I am using both of them as buffered.

PROBLEM
The problem I have is that one of the devices that talks to my device using serial data has it's data rate slightly wrong. The result is that sometimes the data received is scrambled. The problem is that scrambled data is read into the buffer and ingested into my program with the program not realising it is scrambled data.

INVESTIGATION
I observe that the Mega128 has several bits in the UART control register to report status of the UART receive function.
UCSRA1A at $9B bit 4 Frame Error (FE) and Bit 3 Data Over Run (DOR).
It also says that "This bit is set if the next character in the receive buffer had a Frame Error when received. I.e. when the first stop bit of the next character in the receive buffer is zero. This bit is valid until the receive buffer (UDRn) is read. "
As the characters are read out of the received data register by the inbuilt Bascom receive character buffering process, as I understand it, the FE and DOR information is lost by the time I pull the data from the Bascom receive data buffer.

QUESTIONS
Does BASCOM monitor the receive data status bits like FE and DOR and is there a way to get access to that information?

Thanks in advance.

(BASCOM-AVR version : 2.0.8.6 )

JC · Joined: 15 Dec 2007 Posts: 601 Location: Cleveland, OH

Sorry, I can’t answer the specific question that you asked.

When discussing serial comm’s errors, however, it is often helpful provide a little more info:
What is the clock frequency of the M128?
Is the Mega128 using an external crystal for its clock, or the internal oscillator?
What is the baud rate of the M128?
Are there other interrupts running besides the serial comm’s interrupts?
How have you verified that one of the sending unit’s baud rate is slightly wrong? (O’scoped the signal, etc?)
How “slightly wrong” is the transmitted signal?
One generally can tolerate a 2.5 % baud rate error in the transmitter, if the receiver is in spec , (within its 2.5 % error rate limit).

In terms of trouble shooting, it is also helpful to know if you have any control over the transmitting device? Can you select a different baud rate if the one that is being used has a large error rate with the M128’s selected clock frequency?

Can you insert pacing time delays between the transmitted characters, which allows more time for the receiving unit to process the incoming data?
Slowing it down does increase the processing time available for the receiving unit to manage the incoming data stream.
Changing the baud rate can (sometimes) allow you to select a baud rate, based upon the micro's clock frequency, that has 0% or only a very small % baud rate error.

If you take another micro, with an Xtal, and you simulate the transmitted data stream is it then received correctly by the M128, without errors?

If you write a simple program for the M128 to just receive the one channel’s data, (buffered), without the other channel in use, or any other interrupts running, do you still receive errors, or not?

Sorry for all of the questions.
If you only want to know the specific answer about the USART error bits then you can ignore the above.
Otherwise, the extra information might help determine the underlying cause for the problem, and hence the possible solutions.

JC

syndetic1 · Joined: 02 Jan 2007 Posts: 80

Hi JC,
I appreciate your suggestions regarding debugging serial communications however my problem is not tracking that down. My problem is that my program is not at this time able to identify and report that the serial data is not being received accurately. What I wish is to add to my program the capability to report when the data being received is corrupt. In this case I am lucky because I know that the received data is in fixed length packets and for now, I will use that however I use BASCOM for multiple projects and most of those communicate non packetised data. So my wish is to see if BASCOM can report framing errors and data over run errors.
Thanks,
Frank

EDC · Joined: 26 Mar 2014 Posts: 1067

If you use Serialin_x = Buffered then you can also config it Bytematch = All
Then you can easly read:

laborratte · Joined: 27 Jul 2005 Posts: 302 Location: Berlin

Unfortunately EDC's idea will not work, as RX errors (frame, DOR, parity) have to be checked before UDR is read. But the bytematch routine is called after the received byte is read into the buffer.

Bascom's high level serial routines assume error free receiving. If you need to check for errors you have to write your own low level routines.

If async (i.e. temperature depended RC oscillators at sender) is your only problem you may search for autobaud or automatic baud setting. There are solutions which measure the length of startbit to set a proper baudrate for receiving.

EDC · Joined: 26 Mar 2014 Posts: 1067

Yes indeed but maybe this will be not that complicated.
I look into [_GOTCHAR0] routine in the mcs.lib

If TO move that lines:
#IF _CHECKCHAR0=2
call Serial0ByteReceived ; just call user code
#ENDIF

below this lines:
#IF _CHECKCHAR0 <>0
CLT ;clear T
#ENDIF

and recompile the mcs.lib then maybe...this will work Very Happy

albertsm · Joined: 09 Apr 2004 Posts: 6063 Location: Holland

indeed bascom expects error free data.
it does not make much sense to work with garbage data. because what are the option?
- report and then? what good is that?
- ignore this data? but that is also not really convenient.
-data arrives in a stream. so unless you have some protocol reporting a wrong char is not helping.
IMO you can use a checksum to ensure you have the correct data.
and best option it so work on the cause. a variable baud is a good option too.

if you have no control over the sending device you can roll your own code.

syndetic1 · Joined: 02 Jan 2007 Posts: 80

Thanks guys,
Thank you laborratte and albertsm for clarifying that Bascom high level serial routines assume error free receiving.
I will investigate EDC's suggestion - Thank you.