AT91RM900 USART problem

We have been developing code for the AT91RM9200 and have found problems
with the UART when running the USART 1.5% slower than the selected
boaud rate. A natural consequence with certain clocks and the available
divisors available. The problem is that framing errors are not
correctly detected.  i.e for 115200 we have a 18.432 MHz crystal clock,
and processors runs at 179.712MHz, main clock=59.904MHz, UART and the
baud rate divisor is set to 33 (5990400/(16x115200). The calculated
divisor value would be 32.5 and using the Atmel Uart code which rounds
up sets it to 33, 1.5% error ,which should be OK for RS232.  If we set
USART to 8N and send it 7N data we should get framing errors but we
don't. If we set divisor to 32 it then works. This is 1.5% error which
should be OK. This problem occurs for any baud rate that is low by
1.5%. Since the receive data source could be off baud by 1.5% then this
is a serious problem as this products does coms analysis.
Could anybody offer any advice on this problem?

sjones@scannex.co.uk wrote:
> 
> We have been developing code for the AT91RM9200 and have found
> problems with the UART when running the USART 1.5% slower than the
> selected boaud rate. A natural consequence with certain clocks and
> the available divisors available. The problem is that framing
> errors are not correctly detected.  i.e for 115200 we have a
> 18.432 MHz crystal clock, and processors runs at 179.712MHz, main
> clock=59.904MHz, UART and the baud rate divisor is set to 33
> (5990400/(16x115200). The calculated divisor value would be 32.5
> and using the Atmel Uart code which rounds up sets it to 33, 1.5%
> error ,which should be OK for RS232.  If we set USART to 8N and
> send it 7N data we should get framing errors but we don't. If we
> set divisor to 32 it then works. This is 1.5% error which should
> be OK. This problem occurs for any baud rate that is low by 1.5%.
> Since the receive data source could be off baud by 1.5% then this
> is a serious problem as this products does coms analysis.
> Could anybody offer any advice on this problem?

Draw yourself some timing diagrams, remembering that the initial
sync on a 16x clock can introduce an error of 1/16 of a bit time. 
Then consider the drift of the sample points over the 10 bit times
involved.  I think you will find that sloppy UART clock timing
makes your system useless for precise diagnoses.  Don't forget the
error tolerance in the original crystal.

What you could do, if you really want to thrash the external
system, is switch your clock between high and low divisor values,
dependant on the test to be applied.  You can't test both the
receiver and transmitter simultaneously this way.  That would give
you a margin for each test, so you could conclusively say a
function was correct.

Or you could hire me to do the job properly :-)

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

CBFalconer wrote:
> sjones@scannex.co.uk wrote:
> 
>>We have been developing code for the AT91RM9200 and have found
>>problems with the UART when running the USART 1.5% slower than the
>>selected boaud rate. A natural consequence with certain clocks and
>>the available divisors available. The problem is that framing
>>errors are not correctly detected.  i.e for 115200 we have a
>>18.432 MHz crystal clock, and processors runs at 179.712MHz, main
>>clock=59.904MHz, UART and the baud rate divisor is set to 33
>>(5990400/(16x115200). The calculated divisor value would be 32.5
>>and using the Atmel Uart code which rounds up sets it to 33, 1.5%
>>error ,which should be OK for RS232.  If we set USART to 8N and
>>send it 7N data we should get framing errors but we don't. If we
>>set divisor to 32 it then works. This is 1.5% error which should
>>be OK. This problem occurs for any baud rate that is low by 1.5%.
>>Since the receive data source could be off baud by 1.5% then this
>>is a serious problem as this products does coms analysis.
>>Could anybody offer any advice on this problem?
> 
> 
> Draw yourself some timing diagrams, remembering that the initial
> sync on a 16x clock can introduce an error of 1/16 of a bit time. 
> Then consider the drift of the sample points over the 10 bit times
> involved.  I think you will find that sloppy UART clock timing
> makes your system useless for precise diagnoses.  Don't forget the
> error tolerance in the original crystal.
> 
> What you could do, if you really want to thrash the external
> system, is switch your clock between high and low divisor values,
> dependant on the test to be applied.  You can't test both the
> receiver and transmitter simultaneously this way.  That would give
> you a margin for each test, so you could conclusively say a
> function was correct.
> 
> Or you could hire me to do the job properly :-)

Spoken like a man that has written a few
software uarts.

"CBFalconer" <cbfalconer@yahoo.com> wrote in message 
news:443BE949.2618800C@yahoo.com...
> sjones@scannex.co.uk wrote:
>>
>> We have been developing code for the AT91RM9200 and have found
>> problems with the UART when running the USART 1.5% slower than the
>> selected boaud rate. A natural consequence with certain clocks and
>> the available divisors available. The problem is that framing
>> errors are not correctly detected.  i.e for 115200 we have a
>> 18.432 MHz crystal clock, and processors runs at 179.712MHz, main
>> clock=59.904MHz, UART and the baud rate divisor is set to 33
>> (5990400/(16x115200). The calculated divisor value would be 32.5
>> and using the Atmel Uart code which rounds up sets it to 33, 1.5%
>> error ,which should be OK for RS232.  If we set USART to 8N and
>> send it 7N data we should get framing errors but we don't. If we
>> set divisor to 32 it then works. This is 1.5% error which should
>> be OK. This problem occurs for any baud rate that is low by 1.5%.
>> Since the receive data source could be off baud by 1.5% then this
>> is a serious problem as this products does coms analysis.
>> Could anybody offer any advice on this problem?
>
> Draw yourself some timing diagrams, remembering that the initial
> sync on a 16x clock can introduce an error of 1/16 of a bit time.
> Then consider the drift of the sample points over the 10 bit times
> involved.  I think you will find that sloppy UART clock timing
> makes your system useless for precise diagnoses.  Don't forget the
> error tolerance in the original crystal.
>
> What you could do, if you really want to thrash the external
> system, is switch your clock between high and low divisor values,
> dependant on the test to be applied.  You can't test both the
> receiver and transmitter simultaneously this way.  That would give
> you a margin for each test, so you could conclusively say a
> function was correct.
>
> Or you could hire me to do the job properly :-)
>

With no small amount of trepidation :-| I can't help but comment.

The numbers don't seem to add up to enough to create the error.  The 1.5% 
error over 10 bits is still only a 15% error at the end of the 10th bit. 
The 1/16th of a bit time you mention adds another 6.25%.  So the cumulative 
error is only 21.5%.

There are probably exceptions, but UARTS are typically designed to sample 
the Start and Stop bits at the 50% point of bit times (the 8th clock on a 
16x system) to provide the most tolerance.  The error at 1.5% shouldn't be 
enough to cause the error he is getting.

Scott

Not Really Me wrote:
> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
>> sjones@scannex.co.uk wrote:
>>>
>>> We have been developing code for the AT91RM9200 and have found
>>> problems with the UART when running the USART 1.5% slower than the
>>> selected boaud rate. A natural consequence with certain clocks and
>>> the available divisors available. The problem is that framing
>>> errors are not correctly detected.  i.e for 115200 we have a
>>> 18.432 MHz crystal clock, and processors runs at 179.712MHz, main
>>> clock=59.904MHz, UART and the baud rate divisor is set to 33
>>> (5990400/(16x115200). The calculated divisor value would be 32.5
>>> and using the Atmel Uart code which rounds up sets it to 33, 1.5%
>>> error ,which should be OK for RS232.  If we set USART to 8N and
>>> send it 7N data we should get framing errors but we don't. If we
>>> set divisor to 32 it then works. This is 1.5% error which should
>>> be OK. This problem occurs for any baud rate that is low by 1.5%.
>>> Since the receive data source could be off baud by 1.5% then this
>>> is a serious problem as this products does coms analysis.
>>> Could anybody offer any advice on this problem?
>>
>> Draw yourself some timing diagrams, remembering that the initial
>> sync on a 16x clock can introduce an error of 1/16 of a bit time.
>> Then consider the drift of the sample points over the 10 bit times
>> involved.  I think you will find that sloppy UART clock timing
>> makes your system useless for precise diagnoses.  Don't forget the
>> error tolerance in the original crystal.
>>
>> What you could do, if you really want to thrash the external
>> system, is switch your clock between high and low divisor values,
>> dependant on the test to be applied.  You can't test both the
>> receiver and transmitter simultaneously this way.  That would give
>> you a margin for each test, so you could conclusively say a
>> function was correct.
>>
>> Or you could hire me to do the job properly :-)
> 
> With no small amount of trepidation :-| I can't help but comment.
> 
> The numbers don't seem to add up to enough to create the error. 
> The 1.5% error over 10 bits is still only a 15% error at the end
> of the 10th bit. The 1/16th of a bit time you mention adds
> another 6.25%.  So the cumulative error is only 21.5%.
> 
> There are probably exceptions, but UARTS are typically designed
> to sample the Start and Stop bits at the 50% point of bit times
> (the 8th clock on a 16x system) to provide the most tolerance. 
> The error at 1.5% shouldn't be enough to cause the error he is
> getting.

Draw the timing diagrams.  Don't forget to allow for the
uncertainty of the initial syncing on the start bit.  I'm not going
to do it unless he hires me.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

sjones@scannex.co.uk wrote:
> We have been developing code for the AT91RM9200 and have found problems
> with the UART when running the USART 1.5% slower than the selected
> boaud rate. A natural consequence with certain clocks and the available
> divisors available. The problem is that framing errors are not
> correctly detected.  i.e for 115200 we have a 18.432 MHz crystal clock,
> and processors runs at 179.712MHz, main clock=59.904MHz, UART and the
> baud rate divisor is set to 33 (5990400/(16x115200). The calculated
> divisor value would be 32.5 and using the Atmel Uart code which rounds
> up sets it to 33, 1.5% error ,which should be OK for RS232.  If we set
> USART to 8N and send it 7N data we should get framing errors but we
> don't. If we set divisor to 32 it then works. This is 1.5% error which
> should be OK. This problem occurs for any baud rate that is low by
> 1.5%. Since the receive data source could be off baud by 1.5% then this
> is a serious problem as this products does coms analysis.
> Could anybody offer any advice on this problem?

  Sounds like you are pushing this into boundary cases, and need to
create your own data set.
  Since the final word lies with the hardware, with this type of problem
you are best to do some accurate test cases.

  ie the 9200 has multiple UARTS, so start with a low baud rate, and
talking to itself, then creep the skew in both directions, and record 
the error bands.
  That gives you a value for perfectly matched crystals, and phase
stable sample slots.
  Then expand that to two boards, etc

-jg

"CBFalconer" <cbfalconer@yahoo.com> wrote in message 
news:443D328A.E5CF1073@yahoo.com...
> Not Really Me wrote:
>> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
>>> sjones@scannex.co.uk wrote:
>>>>
>>>> We have been developing code for the AT91RM9200 and have found
>>>> problems with the UART when running the USART 1.5% slower than the
>>>> selected boaud rate. A natural consequence with certain clocks and
>>>> the available divisors available. The problem is that framing
>>>> errors are not correctly detected.  i.e for 115200 we have a
>>>> 18.432 MHz crystal clock, and processors runs at 179.712MHz, main
>>>> clock=59.904MHz, UART and the baud rate divisor is set to 33
>>>> (5990400/(16x115200). The calculated divisor value would be 32.5
>>>> and using the Atmel Uart code which rounds up sets it to 33, 1.5%
>>>> error ,which should be OK for RS232.  If we set USART to 8N and
>>>> send it 7N data we should get framing errors but we don't. If we
>>>> set divisor to 32 it then works. This is 1.5% error which should
>>>> be OK. This problem occurs for any baud rate that is low by 1.5%.
>>>> Since the receive data source could be off baud by 1.5% then this
>>>> is a serious problem as this products does coms analysis.
>>>> Could anybody offer any advice on this problem?
>>>
>>> Draw yourself some timing diagrams, remembering that the initial
>>> sync on a 16x clock can introduce an error of 1/16 of a bit time.
>>> Then consider the drift of the sample points over the 10 bit times
>>> involved.  I think you will find that sloppy UART clock timing
>>> makes your system useless for precise diagnoses.  Don't forget the
>>> error tolerance in the original crystal.
>>>
>>> What you could do, if you really want to thrash the external
>>> system, is switch your clock between high and low divisor values,
>>> dependant on the test to be applied.  You can't test both the
>>> receiver and transmitter simultaneously this way.  That would give
>>> you a margin for each test, so you could conclusively say a
>>> function was correct.
>>>
>>> Or you could hire me to do the job properly :-)
>>
>> With no small amount of trepidation :-| I can't help but comment.
>>
>> The numbers don't seem to add up to enough to create the error.
>> The 1.5% error over 10 bits is still only a 15% error at the end
>> of the 10th bit. The 1/16th of a bit time you mention adds
>> another 6.25%.  So the cumulative error is only 21.5%.
>>
>> There are probably exceptions, but UARTS are typically designed
>> to sample the Start and Stop bits at the 50% point of bit times
>> (the 8th clock on a 16x system) to provide the most tolerance.
>> The error at 1.5% shouldn't be enough to cause the error he is
>> getting.
>
> Draw the timing diagrams.  Don't forget to allow for the
> uncertainty of the initial syncing on the start bit.  I'm not going
> to do it unless he hires me.
>
> -- 
> "If you want to post a followup via groups.google.com, don't use
> the broken "Reply" link at the bottom of the article.  Click on
> "show options" at the top of the article, then click on the
> "Reply" at the bottom of the article headers." - Keith Thompson
> More details at: <http://cfaj.freeshell.org/google/>
> Also see <http://www.safalra.com/special/googlegroupsreply/>
>


Is there a _real_ reason not to change the crystal, to one that's baud-rate friendly?
Maybe some other system timing can be derived from that xtal or another osc.
You gotta get the comms right for a piece of comms equipment. #1 priority.

Otherwise divide the 18.432MHz by 10 externally and you've got the baud clock exactly 
right. Can the AT91 accept an external baud clock?


-Andrew M

In comp.arch.embedded,
Andrew M <noone@home> wrote:
>>>> sjones@scannex.co.uk wrote:
>>>>>
>>>>> We have been developing code for the AT91RM9200 and have found
>>>>> problems with the UART when running the USART 1.5% slower than the
>>>>> selected boaud rate. A natural consequence with certain clocks and
>>>>> the available divisors available. The problem is that framing
>>>>> errors are not correctly detected.  i.e for 115200 we have a
>>>>> 18.432 MHz crystal clock, and processors runs at 179.712MHz, main
>>>>> clock=59.904MHz, UART and the baud rate divisor is set to 33
>>>>> (5990400/(16x115200). The calculated divisor value would be 32.5
>
>
> Is there a _real_ reason not to change the crystal, to one that's baud-rate friendly?
> Maybe some other system timing can be derived from that xtal or another osc.
> You gotta get the comms right for a piece of comms equipment. #1 priority.
>

No need to even change the crystal, just set up the PLL and stuff different.
I'm using the same CPU with the same crystal. I run the CPU at 147.456MHz
(crystal x 8), main clock is 73.728MHz, which gives a divisor value of 40
exactly for 115200.

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

We are relying on the framing error detection (amongst other things) of
the USART to lock onto the protocol of the incoming data. In our
initial tests we had problems when the USART was set to 8N (8-bit, no
parity) and the incoming data was 7N - but only when the baud rate was
115200 or 38400.
After a lot of investigation I discovered that the baud rate divisors
for those two values require a half count. The Atmel supplied file
"lib_AT91RM9200.h" rounds up the baud_value in those two instances,
making the 115200 divisor 33 (instead of the precise value of 32.5).
The result is that the USART baud rate is slightly slower than the
incoming rate.
As suggested we could change the clock, however the other side could
have a baud rate error of 1.5% and we would then still miss framing
errors. Baud rate errors of around 4% should be ok with RS232, as
suggested in the Atmel Data Sheet. Having looked at other news groups
this problem has been noted in Atmel ARM 7 devices so is probably a
Silicon bug.
Thanks

sjones@scannex.co.uk wrote:

> We are relying on the framing error detection (amongst other things) of
> the USART to lock onto the protocol of the incoming data. In our
> initial tests we had problems when the USART was set to 8N (8-bit, no
> parity) and the incoming data was 7N - but only when the baud rate was
> 115200 or 38400.
> After a lot of investigation I discovered that the baud rate divisors
> for those two values require a half count. The Atmel supplied file
> "lib_AT91RM9200.h" rounds up the baud_value in those two instances,
> making the 115200 divisor 33 (instead of the precise value of 32.5).
> The result is that the USART baud rate is slightly slower than the
> incoming rate.
> As suggested we could change the clock, however the other side could
> have a baud rate error of 1.5% and we would then still miss framing
> errors. 

  A possible work around, would be to try both values - ie if you know
data is arriving, but do not see the expected FE Sync infos, then
toggle divisor value, and listen some more...
  You may also find the FE issue is not symmetric.
  A bit of a kludge, but sometimes that's all you can do...

> Baud rate errors of around 4% should be ok with RS232, as
> suggested in the Atmel Data Sheet. Having looked at other news groups
> this problem has been noted in Atmel ARM 7 devices so is probably a
> Silicon bug.

Described this way, probably yes.
What you are doing is also not likely to have been thoroughly tested...

I've seen UART bugs over time, related to not sampling early enough for
the next start bit. It is possible that the frame error sampling is
not as 'central' as it should be, as at this point the UART
will be a little mode-split: Ready for new start bit edge, and also
checking for FE overruns.

Fractional baud divisors also seem to be comming more common, where the
normal /16 is not fixed, but allowed to jitter along the frame, for 
finer sample controls.

-jg