MSP430F67791: MSP430Ware Library Routine Issues: ucs.c

Jim,

Regarding issue 1:

The possible definitions of xcap are as follows:

#define XCAP_0                 (0x0000)       /* XIN/XOUT Cap 0 */
#define XCAP_1                 (0x0004)       /* XIN/XOUT Cap 1 */
#define XCAP_2                 (0x0008)       /* XIN/XOUT Cap 2 */
#define XCAP_3                 (0x000C)       /* XIN/XOUT Cap 3 */

These definitions are set up so that there is no shifting needed by the function call. By referring to Figure 5-12 of the MSP430F5xx/6xx User's Guide you can see that the XCAP bits are in position 3 and 2 of the UCSCTL6 register. Those bits are correctly set by the library's line of code: 

HWREG16(UCS_BASE + OFS_UCSCTL6) |= xcap;

Regarding issue 2:

Section 5.2.12 of the MSP430F5xx/6xx User's Guide explains what happens when a fault is detected for the oscillator sourcing MCLK:

If a fault is detected for the oscillator sourcing MCLK, MCLK is automatically switched to the DCO for its clock source (DCOCLKDIV) for all clock sources except XT1 LF mode. If MCLK is sourced from XT1 in LF mode, an oscillator fault causes MCLK to be automatically switched to the REFO for its clock source (REFOCLK). This does not change the SELM bit settings. This condition must be handled by user software.

The same is the case for SMCLK. The bits need to be cleared so that the correct clock source is selected regardless of the original state of SELM and SELS.

Best regards,

Matt

Matt, you're correct - I had created #defines to reflect the cap value (2pF, 6pF ...) in the symbol name and missed the shift was built-in to your definitions.

On the second issue, this leads to a follow up question on an issue we're having. Our XT1 oscillator appears to not be starting - we're assuming we've selected a crystal that doesn't match what the MSP needs or our load caps are incorrectly sized (still looking here), but the odd thing is after we start XT1 with function "UCS_turnOnLFXT1WithTimeout" the do-while loop testing XT1LFOFFG falls through - Its set on entry but doesn't set a 2nd time after the first clear ... implying the XT1 is not faulted.

We've tested downstream logic using REF0 as the source and verified we're controlling and observing ACLK, MCLK, and SMCLK on external pins. Observing these sources with a XT1 as the reference clock gives a non-oscillating high. What condition may cause XT1LFOFFG to not be set while XT1 is not running? The second indicator this is indeed the case is the initial issue I pointed out - as soon as SELM is cleared the MSP and debug session lock up (ie as if the core did switch to XT1 seeing it not faulted, but yet XT1 wasn't running).

Thanks ... Jim

Jim,

Have you checked the "return status" of the UCS_turnOnLFXT1WithTimeout function call? The do-while loop will always fall through, it depends on the return status as to whether or not the crystal was turned on properly.

What crystal and loading caps are you using? Have you tried loading a basic XT1 code example from the TI Resource Explorer to make sure that the hardware surrounding the low frequency crystal is correct?

Best regards,

Matt

Matt, yes the return status is pass. And when I break at "return (STATUS_SUCCESS);" within UCS_turnOnLFXT1WithTimeout the timeout value is 32000 - the same value passed in. So the first test of XT1LFOFFG passes (I did verify XT1LFOFFG is set coming in to the "do" - it holds the first clear).

Our XT1 is using an NDK crystal, part number NX3215SA-32.768K-STD-MUA-8 (ESR 70kohms, Cl = 12.5pF). The load caps are 0603, 10pF, NPO and the routing is very short - ground plane on layer 2. I've tried multiple xcap and drive levels in UCSCTL6 while viewing ACLK with no success.

I have tried code from the EVM430-F6779 but not from the examples - I'll go try that now.

Thanks ... Jim

Matt, I'm wondering now if I'm using the wrong library. I added "ucs_ex3_XT1SourcesACLK.c" from "\MSP430Ware_3_80_05_04\driverlib\examples\MSP430F5xx_6xx\ucs" and see its enabling ACLK on P11.0. This doesn't match the MSP430F67791A we're using which maps the clock to P1 ... what library should we be using for this device?

... Jim

One more data-point ...
I used "msp430f677xA_ucs_4.c" under the examples for the MSP430F67791A (zip file slac648e)
path is \MSP430F677x(1)A_MSP430F676x(1)A_MSP430F674x(1)A_Code_Examples\C.

I added these lines to route XT1 to ACLK ...
UCS_initClockSignal(
UCS_ACLK,
UCS_XT1CLK_SELECT,
UCS_CLOCK_DIVIDER_2
);

... and see a flat line on ACLK. XT1 seems to not be running.

USCTL4 is 0x0044.
Poke 0x0244 into UCSCTL4 and I see REF0 Div by 2 on P1.2 as expected - ACLK is enabled to the pin.
Throughout, UCSCTL7 = 0x0F11.

It still seems to imply XT1 is not starting, but yet XT1LFOFFG is not being set?

Complete UCS values in this state ...
UCSCTL0 = 0x00F8
UCSCTL1 = 0x0030
UCSCTL2 = 0x104A
UCSCTL3 = 0x0000
UCSCTL4 = 0x0244
UCSCTL5 = 0x0100
UCSCTL6 = 0xC1CC
UCSCTL7 = 0x0F11
UCSCTL8 = 0x0707

Jim,

The best way to import examples is by using the TI Resource Explorer inside of CCS ( View -> Resource Explorer ). This ensures that the correct libraries and paths are set for the corresponding device.

To import the UCS driverlib example, you would navigate to "Software -> MSP430Ware -> Libraries -> Driver Library -> MSP430F5xx_6xx -> Example Projects -> UCS -> click on the example that uses the XT1 to source ACLK and then use the CCS symbol in the top right of the window to import the project. This is a default driverlib example so you will need to go into Project Properties -> General and then select the correct device you are using. This should set you up to use the correct libraries with the proper definitions for your specific device.

To import the register level example you described above, navigate to "Software -> MSP430Ware -> Devices -> MSP430F5xx_6xx -> MSP430F67791A -> Peripheral Examples -> Register Level -> click on the example that uses the XT1 to source ACLK and then use the CCS symbol in the top right of the window to import the project. This will import a project that is already tailored specifically for your device.

Use a very basic register level example that uses the XT1 and outputs it on a GPIO so that you can see if the error is in the hardware or software of the application. Since you are using a custom PCB please make sure that the GPIO used to output the XT1 signal is not being sent to another IC on your board.

Best regards,

Matt

Matt, imported and built the example (ucs_ex3_XT1SourcesACLK) with the Resource Explorer followed by setting the Family Variant to MSP430F67791A for the project. Still two items I can't explain.

First, the file imported still uses port mapping that doesn't match the '67791A (below) ...

_______

void main (void)
{
//Stop watchdog timer
WDT_A_hold(WDT_A_BASE);

//Set P1.0 to output direction
GPIO_setAsOutputPin(
GPIO_PORT_P1,
GPIO_PIN0
);

//Set P11.0 to output direction
//P11.0 to output ACLK
//Select XT1
GPIO_setAsPeripheralModuleFunctionOutputPin(
GPIO_PORT_P11,
GPIO_PIN0
);

//Port select XT1
GPIO_setAsPeripheralModuleFunctionInputPin(
GPIO_PORT_P7,
GPIO_PIN0 + GPIO_PIN1
);

_____

And second, the code runs fine but hangs looping in UCS_clearAllOscFlagsWithTimeout called from the ISR.

UCSCTL7 is stuck at 0x0F11 - DCO fault flag set. ACLK (P1.2) is sitting low but was never properly mapped due to the issue above. I still don't believe XT1 is starting, yet I'm never seeing XT1LFOFFG set.

Running out of ideas ...