Is 9600 baud viable on a 439 when clocked from ACLK?
"Andrew McLaren" <[email protected]>
| Newsgroups | gmane.comp.hardware.texas-instruments.msp430.gcc.user |
|---|---|
| Organization | Aratika NZ |
| Message-ID | <11D3A7CD91F24F85B7AA5AB19B1BCA2F@jupiter> |
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 [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users