Problem in setting the UART baud rate in MSP430FR5739

I found one more thing.

I just changed the baud rate to the one which we are going to use in the field, i.e 921600,

Following are the settings,

        UCA0BRW = 0x01;       
        UCA0MCTLW = 0x01a1;

But with this high baud rate always the first few bytes (2-4 bytes) are always missing. but rest of all the data is being received properly.

I am just wondering how could this be possible to lose only the starting bytes

chethu gowda said:

I am just wondering how could this be possible to lose only the starting bytes

Did you check for RXBUF overflows? Maybe your code is at the start not fast enough to handle this baudrate. You only have 8µs per byte at this speed. Even on 16MHz MCLK this isn't that much.
I assume that you're using such a clock speed, since you are enabling oversampling mode at a divider of 1. However, oversampling mode isn't recommended if the clock speed isn't significantly higher than the baudrate. "Significantly" measn that the remaining baudrate divider after teh /16 for the oversampling is still somewhat above 1. :)

Hi Jens-Michael,

Jens-Michael Gross said:

. You only have 8µs per byte at this speed. Even on 16MHz MCLK this isn't that much.

I am running the MCLK at it's full power of 24MHz, and SMCLK too at 24MHz,

correcting my previous observation I am loosing only the first 2 bytes of the string whenever I receive the data. This data loss never happened when I was running with following clock configuratoin

MCLK - 8MHz and SMCLK - 1MHz, and with this settings the same baud rate of 921600bps worked absolutely fine.

But with the current clock setting the same operation should be more efficient as the cpu is running at 24MHz and the UART is driven by SMCLK with such a high clock speed of 24MHz.

Please clarify about this.

Hi old_cow_yellow,

old_cow_yellow said:

If you are using the MSP-EXP430FR5739 board, the Application UART interface to PC USB is only capable of doing 2400, 4800, and 9600 b/s. You cannot use 115200 b/s.

The MAX232 chipset that I am using for TTL conversion has the limitation of 200kbps using which I have communicated successfully with PC at 115200 many times,

But the only difference now in the setting is the SMCLK and MCLK frequency, which are increased from 1MHz to 24MHz, except that there are no other changes. May be issue is with the baud rate generation which I am wondering what I have missed.

Hi old_cow_yellow,

old_cow_yellow said:

If you are using the MSP-EXP430FR5739 board, the Application UART interface to PC USB is only capable of doing 2400, 4800, and 9600 b/s. You cannot use 115200 b/s.

Yes you are absolutely correct I was using the "Application UART interface to PC USB" to communicate with PC , now connected using the RS232 cable through Max232 converter which is working very well with the same baud rate settings..

chethu gowda said:

due to the delay caused by the FLL sustaining time

FLL? Teh FR doesn't have an explicit FLL. However, you're right, switching on the DCO takes some time.
But even if it were much faster (~6µs on F5x family), this would mean that after the first start bit edge that reactivates the clocks, the DCO won't provide the clock for the baudrate for 6µs so you'll lose the first byte in any way.
On some 5x family MSPs, having the UART active prevents switching off the UART clock source (unconditional request), so maybe LPM0 is the deepest you can get.

chethu gowda said:

But in the above link Mr.Jotux is referring to some FR5739 spec which I could not find . Please let me know where can I find the information about such FLL drifts.

it's not a drift. LPM3 has switched off the clock source. And it takes time to bring it up again. That's all. And the latest FR5xx device datasheet lists the wakeup time form different LPMs. (Page 57)

LPM1/2 it is only 12 to 25µs and 0.58 to 1µs for LPM0.

Well, you can't keep the cake and eat it. When you suspend your PC to disk to save power, it will too take much more time to be operational again than when just activating the screensaver.

Hi Jens-Michael Gross,

Jens-Michael Gross said:

this would mean that after the first start bit edge that reactivates the clocks, the DCO won't provide the clock for the baudrate for 6µs so you'll lose the first byte in any way.

According to the FR5739 datasheet the wakeup time from LPM3 is typically 78us and maximum of 120us (assume minimum is not mentioned because program need to support the worst case scenarios ???) With the baudrate of 921600 I was constantly losing 2 bytes which means there was a delay of 17.36us.
To resolve this I used LPM3 itself by appending few dummy characters (in dis case 2 characters "xx") and the result was absolutely fine, the received data was as if there was no "xx" at the beginning of the string. Is it recommended to use such dummy characters? I mean will the wakeup time be constantly ~17us always?

In the datasheet I can see something called "complete data retention" under LPM3 (page 20 of datasheet) how is it dependent on the LPM mode?

chethu gowda said:

will the wakeup time be constantly ~17us always?

On this MSP, likely. On all MSPs of the same type? not likely.

Also, the 78µs refer to a lock signal that prevents MCLK from starting whiel teh DCo is still unstable. It does nto prevent SMCLK form being clocked and so the attached modules. So the UART gets a clock much sooner, but it is not guaranteed to be stable and correct. Yuo may or may not receive anything. If the UART discards the first two bytes because they are nonsense, it may or ma ynot properly receive the 3rd and most of teh 4th when the CPU is finally activated and reads the first and finally 4th byte of a transmission.

chethu gowda said:

Is it recommended to use such dummy characters?

If you use LPM3, yes, this is a good way. However, I wouldn't rely on a fixed number of dummies to be discarded. A typical way is to send a preamble of several dummy characters of a value that is obviously invalid. So if you send, say, 6* 0xff while the first byte of a message cannot be 0xff, then the receiver can safely discard any 0xff it receives until the first byte that is not 0xff.
It then makes no difference how many bytes at the beginning you miss, as long as it aren't more than the size of the preamble.
Of course every preamble-byte adds to the total transmission time.

Jens-Michael Gross said:

ypical way is to send a preamble of several dummy characters of a value that is obviously invalid.

yes dats how its done as of now.. and is working gr8.. with this Im happy dat i never have to compromise with the power consumption.. :)

One more thing which was not noticed in my earlier reply is about "data retention" in FRAM. Please explain how would it be dependent on the LPM, any link explaining the same is also helpful.. Hope m not overloading you with small stuffs :(

chethu gowda said:

One more thing which was not noticed in my earlier reply is about "data retention" in FRAM.

I'm not sure whether this has to do with FRAM at all.

FRAM is non-volatile and its data retention time is many years after power-off.

I guess this referes to the small SRAM part (2k, IIRC). It basically means that the SRAM is still powered. In LPM4.5 or 3.5, it isn't and data in ram is lost.
AFAIK, the linker generally doesn't use SRAM at all for standard projects. The double-usage of FRAM as ROM and RAM likewise is not really supported by the linker. So FRAM has been deliberately divided into two parts with predefined size. One for ROM, one for RAM. Including variables and stack. SRAM is left aside unless you reconfigure the linker.
However, during LPM3, RAM is still powered and retains its content. And consumes energy. That's what this line means.

why?

Teh applicaiton UART is a software-driven secondary serial channel in teh USB/SER chip of the programmer. It simply isn't fast enough to bit-bang more than 9600Bd. That's it. The high-speed serial hardware of this chip is used to interface the FET to the PC.
The MSP itself can use higher baudrates but not when using the application UART. You'll need to use a separate USB/SER converter if you need highe rspeed.

However, on newer evaluation boards/LaunchPads that do no longer use the TUSB and MSP430F1612 combo for the FET, the application UART is no longer limited to 9600Bd.