1
\$\begingroup\$

I am trying to learn about UART Serial communication of the MSP430FR6989 from Texas Instruments.

Datasheet

User's Guide

I doing a program where my UART will send a character through the TX pin of my microcontroller and receives it through the RX pin.


If we take a look at the Block Diagram of the MSP430's UART module (eUSCI - UART Mode), it will look like this

enter image description here

(Page 766/1021 of UG)

A 32.768 kHz Auxiliary Clock Source will be the source of the BRCLK (Baud Rate Clock), I will enable the Parity bit (UCPEN = 1), and set it to count even 1s (UCPAR = 1). I will put a value of odd 1s into the Transmission buffer (UCA0TXBUF = 1001 0111). Now I expect the Parity Error Flag to be set (UCPE 0-> 1).

enter image description here

(Page 784/1021 of UG)

enter image description here

(Page 787/1021 of UG)


This is a snippet of the code

int main(void)
{   
    //code

    set_Clock_Signals (); //sets f(ACLK) = 32.768 kHz
    set_UART_Pins (); //P4.2 and P4.3 are UART RX and TX
    set_UART_Baud_Rate ();

    UCA0CTLW0 = UCSWRST; //put UART in reset mode

    UCA0CTLW0 = UCA0CTLW0 | UCPEN | UCPAR | UCSSEL0;
    //enables parity, parity is even, selects ACLK CS

    UCA0CTLW0 = UCA0CTLW0 & (~UCSWRST); 
    //we can send and recieve data now

    UCA0TXBUF = 0x57; //Line A
    //0101 0111

    while(1);

    return 0;
}

I build program, and started debugging it, what I expected was when the debugger steps into Line A, and steps out of it, I will see UCPE bit to be set, but instead I didn't get an error.

enter image description here

Steps into the next line, no error, and it works fine.

enter image description here

\$\endgroup\$
10
  • 2
    \$\begingroup\$ i do not see a question \$\endgroup\$
    – jsotola
    Oct 3, 2018 at 3:00
  • 3
    \$\begingroup\$ Why do you expect to get a parity error? The parity bit is en extra bit the UART calculates itself & sends based on the data bits you write. Parity is a 9th bit of data. \$\endgroup\$
    – brhans
    Oct 3, 2018 at 3:04
  • 1
    \$\begingroup\$ the reason why you do not get an error is because the receiver has received all the bits correctly .... none of the bits were corrupted ..... (note: some multibit errors would not be detected) \$\endgroup\$
    – jsotola
    Oct 3, 2018 at 3:31
  • 3
    \$\begingroup\$ you did not set the parity bit .... you enabled the transmitter to generate a parity bit ..... you cannot choose the parity bit value directly \$\endgroup\$
    – jsotola
    Oct 3, 2018 at 3:34
  • 1
    \$\begingroup\$ you need to review information about the parity bit and how it is used \$\endgroup\$
    – jsotola
    Oct 3, 2018 at 3:35

1 Answer 1

4
\$\begingroup\$

When you set UCPEN, the hardware sends (and expects to receive) an additional bit:

MSP430 eUSCI UART character format

If the actual data bits D0…D7 already have the correct parity, the PA bit is transmitted as zero. If the D0…D7 parity is wrong, the PA bit is set to one, so that the parity of all bits together comes out right.

The parity checking mechanism never restricts what data bytes you can send; its only purpose is to detect (some) transmission errors.


As long as you are using the same eUSCI module with the same configuration, it is not possible to force a parity error. What you'd have to do is to use two different UARTs, configure the sender for eight data bits without parity, and the receiver for seven data bits with parity. The sender's D7 bit can then be set to a value that does not match the receiver's expected parity.

\$\endgroup\$
1
  • 2
    \$\begingroup\$ +1 because the test method was described. Looping back UART data should NEVER fail on parity or framing as it generates them just right. You need to introduce a error in generation or in the transmission path. \$\endgroup\$
    – KalleMP
    Oct 3, 2018 at 9:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.