Problems with using UART in MSP430F6721

PeterG said:

. I look at the clock on PJ.3 and it is at 32KHz. I use ACLK for the baudrate clock and have a baudrate of 9600. I set UCA0BR0 to 0x3. I try and transmit a byte and find that the bit width is 92uS rather than 104uS.

32KHz crystal or 32.768KHz crystal?

Setting UCAxBR0 to 0x03 with an ACLK of 32KHz will indeed give you a bit period of 92 us. 1 / (32786/3) = 0.0000915....

PeterG said:

I find I cannot write to the MCTL register.

You need to make sure that UCSWRST is set to a 1 before changing settings in MCTL. (I see now that you say that...) Are you sure that your register addresses are correct?

PeterG said:

Any thoughts as to what I am doing wrong?

Can you post the code fragment?

Brian

I am using a 32768 crystal. UCAxBR0 is 0x03 for 9600 baud. Check page 905 in teh user guide and other user guides I have been using this figure in many designs over quite a few years. I have UCSWRST set to 1 when changing registers. I believe the problem is in my not being able to change the MCTL register.
My code is
SetupUART0 bis.b #UCSWRST,&UCA0CTL1 ;set it to modify registers
bis.b #UCSSEL_1,&UCA0CTL1 ;ACLK
mov.b #03h,&UCA0BR0 ;9600 baud, clock off ACLK
clr.b &UCA0BR1
bis.b #BIT2+BIT3,&P1SEL ;enable for UART ops
bis.w #0006h,&UCA0MCTLW
bic.b #UCSWRST,&UCA0CTL1 ;start it
Notice that the MCTL register is now 16 bits. This command does nothing to the UCAxMCTLW register, it remains at 0x0000

Thanks

Peter

I found the problem. The MCTL register is addressed very differently to other MCUs that I have used. The user guide is not clear on this. If anyone has similar problems I would be happy to respond.

The USCI module has an 8 bit MCTL register with a 3-bit selector for the second stage modulation pattern. On the eUSCI module, the register has been changed to 16 bit, with an 8 bit field for directly specifying the second stage modulation pattern.

However, what's 'unusual' with the modulation register? Agreed, the modulation itself is 'unusual'. Many other MCUs don't have such a thing at all, requiring a specific clock source (that's why the 14.7456MHz crystals exist, as this is 128*115200), or you have to live with the bit error and require a clock that is as high as possible to make the fractional error in the divider as small as possible.
I agree that the users guide is not exhaustive explaining the UCBRSx bits, but table 47-4 gives you a list of values for certain fractional ranges. It doesn't help for automatically calculated settings, though.

I started using the MSP430F1121A initially in teh TI range. Since that time, many moons ago I have now progressed through the F21xx series, the F2xx series and now the Fram and F5/6xxx MCUs. I can understand how the setups change as the chips get more complex and offer greater flexibility. Howevr, gone are the days when you can readily switch from one MCU to another and make minimal changes to your code. It is now a major effort to switch to a new MCU version. It is now to the stage where you can consider another supplier as you know the effort at a new chip will not be a lot different to a new TI MCU

In relation to the manual a supplier once said to me that the only good manuals he had seen were those written by professional manual writers. I must agree with him. It is not just TI but many companies who pay little attention to how manuals are written and how well understood. TI is one of the better ones, in my opinion. A well written manual can save you many frustrating hours and endear you to teh customer. 

Thanks for your response 

Peter

Peter,

This is one of the things that driverlib is intended to help alleviate. The API is essentially the same regardless of which MSP is underneath. This helps in the portability aspect.

For some projects, the overhead of the driverlib might be overkill or too resource intensive (memory). There you can code in a more "direct hardware access" method. But your trade is future portability. In engineering nothing is perfect, it is all about tradeoffs.

The main thing that changes between MSP families is the clock system. But the basic concept has remained the same for almost everything.
Of course new features require new code, but in most cases, existing low-level code for peripherals can be re-used without or with only minor changes. The timers haven't changed, the ADCs are mostly backwards compatible to the ones (ADC12 almost completely, ADC10 with changes regarding DMA instead of DTC), port I/O the same. The thing that has changed most are the UARTs from USART to USCI to eUSCI (with the USI as sidestep).
To overcome those, changes, the driverlib, as it evolves, helps to provide compatibility. However, I don't like the overhead of its API.
My low-level code base supports the 1232, the 1611 and the 5438 (and many others, though never tested) as well as the ATMega128. All modules can be included into any projects for any of these and compile with minimum overhead (code size and code execution). So the mid-level code using them runs almost (except for some global defines) unchanged on all four. Provided that the chip offers all needed hardware (the 1232 code runs on all others, the ATMega code of course not on the 1232 due to lack of flash and ram).

The main thing is, that when switching between MSP families, most of the concepts you learned are still valid. While on other MCU lines, a new MCU, even if of the same series, requires you to almost start from scratch.
The problem is that the users guides do not really explain the concepts as such, they do so on the explicit hardware of one family. So it isn't easy for everyone to see what remains the same and what changes between families.
In my book (which I'll probably never finish), I tried to explain the concepts and how the modules work together, rather than the individual implementation of a hardware module. Focusing on the 'why' rather than the detailed 'how'. That's what's missing on the users guides. Once you got it, migrating is much easier than between any competitor's devices.