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?
Reply to
sjones
Loading thread data ...

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

Reply to
Not Really Me

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

Reply to
Jim Granville

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

Reply to
Andrew M

friendly?

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)
Reply to
Stef

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
Reply to
sjones

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...

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

Reply to
Jim Granville

The USART3 present in the SAM7 chips and the forthcoming cost reduction of the 9200 (AT91SAM9260) has a fractional baud rate generator, but that and the Manchester Codec is well hidden in the datasheet.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

skrev i meddelandet news: snipped-for-privacy@t31g2000cwb.googlegroups.com...

The new USART has a fractional BAUD rate divisor but it was not available at the time of the 9200. It may be possible to reprogram the PLL so you get an exact value.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.