Could I do a bit of a sanity check on my thinking!
I'm running a 439, and part of its logic talks to a RS232 device (a Coronis
Wavecard, but I think that's irrelevant) via its USART at 9600 baud. The
logic is primarily running at LPM3, and one of the awakening mechanisms is
Rx data from the USART. Because of this, the USART is clocked from the ACLK.
The logic can run perfectly for days, then suddenly fail with the Rx
interrupt handler failing to detect any incoming data. I've had an RS232
monitor on the Rx line, and all looks fine there - the data is coming, and
appears well formed, but the interrupt handler seems to have gone AWOL.
Because of the large and indeterminate interval between failures, its been
difficult to try and get a handle on what is happening. All the USART
registers appear intact, but re-executing the USART initialisation logic
brings things back to life.
After some months with this smouldering in the background, I finally had a
look at the errata for this device (I can be a bit slow...), and there in
black and white is the possible (maybe probable) cause of the problem;
US14 (USART module)
Function: Start edge of receiceived characters may be ignored
Description: When using the USART in UART mode with UxBR0 = 0x03 and UxBR1 =
0x00, the start edge of received characters may be ignored due to internal
timing conflicts within the UART state machine. The condition does not apply
when UxBR0 > 0x03
Workaround: None
With 9600 baud, BR0 = 0x03, and BR1 = 0x00.
If I understand how the baud rate is configured (I generally just use the
tables), BR1 and BR0 form a 16 bit word which effectively defines the start
point of the bit timing, with the modulation setting providing a fractional
increase in this to get to the required baud rate (ie. the modulation
increases the bit timing, and hence decreases the baud rate). With the 32K
BRCLK from ACLK, BR1:BR0 = 0x03 gives the start point around 11K, but
increasing this to BR0 = 0x04 gives the starting baud rate at 8K. On this
basis, I can't safely configure the 439 USART to run at 9600 baud unless I
run a faster BRCLK than the 32K ACLK, which then has LPM3 implications. Am I
reading this correctly?
The obvious solution would be to migrate to a later USCI based device, but
even the later USARTs (such as the 4618) don't have this listed as a
problem. I have a 4618 here, so am going to try running the logic via its
USART to see if I can get the problem to exhibit there. The other
possibility is to drop the communication rate to 4800 baud - 9600 is the
default for the RF device, but the data is minimal so little impact from a
slower baud rate.
Andrew
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
