I have a an application that uses eUSCI_A0 at 115200 Bd, 8 data bits, 1 stop bit and odd parity. Some characters do not get through in either direction and it seems this is due to incorrect handling of the parity bit by the built-in USB-serial converter. Using another USB-serial converter (CP2102-based) everything works as expected.
The program sends the string "Initialization done" upon startup. Using picocom on my Linux PC I receive this as "itilitiooe". Investigating further I found that the string "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" is received as "03569cefijloqrtwxABDGHKMNPSUVYZ". Coincidentally all the characters are missing where the parity bit would be '0', I guess this is detected as an invalid stop bit. picocom output and scope trace (at the jumper on the board marked as "TXD>>") are as follows:
picocom v3.1
port is : /dev/ttyACM1
flowcontrol : none
baudrate is : 115200
parity is : odd
databits are : 8
stopbits are : 1
escape is : C-a
local echo is : no
noinit is : no
noreset is : no
hangup is : no
nolock is : no
send_cmd is : sz -vv
receive_cmd is : rz -vv -E
imap is :
omap is : crlf,
emap is : crcrlf,delbs,
logfile is : none
initstring : none
exit_after is : not set
exit is : no
Type [C-a] [C-h] to see available commands
Terminal ready
itilitiooe
03569cefijloqrtwxABDGHKMNPSUVYZ

With the scope's serial decoder set to parity=none you can see that the characters "I" and "n" which aren't received have an error marker at the end.
The board also doesn't generate the parity bit in the RX direction: Sending "I" with picocom (parity bit set to odd) yields the following scope trace ("RXD<<" on the board; serial decoder set to parity=odd this time!):

As you can see, there is no parity bit generated. The MSP430 program doesn't receive the character (as it should if the parity bit is wrong).
When I don't enable the parity bit on the MSP430 side (not setting/clearing UCPEN of UCA0CTLW0), the communication between the microcontroller and picocom work correctly.
This seems like a bug of the eZ-FET firmware. picocom is directing the driver to enable the parity bit, as evidenced by the fact that it works with a CP2102-based board and also this output from 'stty -F /dev/ttyACM1 -a' (note the "parenb parodd"):
speed 115200 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; parenb parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc
Has there been a new firmware release? How would I go about flashing it if there is one?
