• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 80 subscribers
  • Views 1763 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR5739 UCRXIFG not being set on some bytes

Jason Rinckey
Prodigy 120 points
Other Parts Discussed in Thread: MSP-EXP430FR5739

 I'm having trouble with receiving bytes from a PC. PC is configured for 9600 baud. MSP430 is configured as below for 9600baud. Oscilloscope measurement confirms the datarate is 9600.
The issue I see is that some characters are recognized, but others are not.
The UCA0STATW.UCBUSY flag is set during the byte transfers, but UCRXIFG is only set on certain bytes, causing intermittent data reception.

I am using the Experimenters board so I am limited to 9600 baud, but I would expect a 1.5MHZ source clock to be more than sufficient for UART communications.

Do I need a better clock source than the built in DCO to get UART communication to work?

/*

* Source clock is DCO @ 24MHz. SMCLK = DCO/16
* SMCLK = 1.5Mhz BRCLK = 9600. N = 156 (.25)
* 156.25/16 = 9.76
* 0.76*16 = 12.25
* UCBTSx = 0x44 from lookup table (0.2503)
*/
UCA0CTLW0 = UCSSEL0 + UCSSEL1 + UCSWRST + UCPEN;
UCA0CTLW1 = UCGLIT_0;//2ns De-glitch time
UCA0BRW = 9;//configure the baud rate generator
UCA0MCTLW = (0x4400) + (12 << 4) + UCOS16;// configure the baud rate generator
UCA0CTLW0 &= ~UCSWRST;//Clear software reset.
 
  • 0
    Guru 34453 points

    Try with (simple) TI UART examples from slac300 "MSP430F552x C Examples (IAR and CCSv4)".

    For LF BR mode (UCOS16 = 0), you can use my calculator (http://forum.43oh.com/topic/2640-uart-configurator) for UART setup.

    1 MHz BRCLK is more than enough for 115200 bps, and MSP430 can go over 1 Mbps without problems (http://forum.43oh.com/topic/3413-msp430-uart-benchmark).

  • 0 in reply to zrno soli
    Prodigy 120 points

    I've tried a few different things, all without success. It still only recognizes some characters and not others.

    All that is in my main loop (no interrupts) is:

    if (UCA0IFG & UCRXIFG)
    {
    RX_BYTE=UCA0RXBUF;
    UCA0IFG &= ~UCRXIFG;
    P2OUT ^= BIT6;
    } 
    and I monitor P2.6 for a toggle.

    I tried setting UCOS16 = 0, and just have UCABR0 = 156. same behaviour.

    I enabled the SMCLK output and it measured 1.48453MHz, which is only about 1% error.

    I tried changing the settings to match that frequency. Same behaviour.

    Using a function generator, I put 1.5000MHz into XT1 and ran SMCLK from that source. Same behaviour.

    I tried putting in a clock of 1.2288MHz ( 9600*128 = 1228800) and UCA0BR0 = 128 (with UCOS16=0) Same behaviour.

    Same1.2288MHz clock with UCA0BR0 = 8, and UCOS16=1. Same behaviour.

  • 0 in reply to Jason Rinckey
    Prodigy 120 points

     Issue is with the MSP-EXP430FR5739 (Rev1.1) experimenters board. It only supports 9600baud (which is acceptable at this point), but also doesn't have parity support (not ok). Once I removed the UCPEN bit from the setup, it worked. I had expected to get the RX flag first and then read the errors to see I had a parity error (but this isn't how it worked). On parity error the RX flag wasn't thrown nor was the parity error flag thrown.

    That would have been nice to have in the documentation for the experimenters board...

     

  • 0 in reply to Jason Rinckey
    Guru 227245 points

    Jason Rinckey said:
    On parity error the RX flag wasn't thrown nor was the parity error flag thrown.

    It's possible that you got a framing error instead (when the MSP was receiving the start bit of the next byte as stop bit due to the missing parity bit). Sicne parity is calculated after the stop bit was received, framing error gets diagnosed first and the byte is discarded.

  • 0 in reply to Jens-Michael Gross
    Guru 12160 points

    Hi Jason,

    Sorry if I'm just stating the obvious, but you must make sure all of the communications settings, not just baud rate, match between the MSP430 and the PC.  Besides baud rate, but there are two other critical settings -- parity (E/O/N) and number of stop bits (1/2).  If you don't configure these settings to match between the MSP430 and the PC, your communication won't work right.

    I think the eval kit probably does support parity correctly, but it sounds like you may not have configured the PC to match.

    Jeff

  • 0 in reply to Jeff Tenney
    Prodigy 120 points

    Jeff,

    That is the first thing that I check. Both had odd parity set, both had 1 stop bit, both had 9600 baud. When I probed the RXD pin, the parity bit was being stripped and a constant value was inserted. For ?? reason the eval board routes the UART data through another microcontroller first, rather than from the USB-UART chip direct to the FR5739. Thus I am stuck at 9600 baud and no parity for this eval board as that is what the other microcontroller is programmed to do. Schematic is in slau272b.

**Attention** This is a public forum