Forums

Hmmm,

Could this be the magic foo-foo dust:

while(BAKCTL & LOCKIO) // Unlock XT1 pins for operation
BAKCTL &= ~(LOCKIO);

Regards,
johnw 

johnw

Could this be the magic foo-foo dust:

while(BAKCTL & LOCKIO) // Unlock XT1 pins for operation
BAKCTL &= ~(LOCKIO);

No. Unless you're working with battery backup and LPMx.5

If the chip has dedicated XIN and XOUT pins, then XT1 is active as soon as the XT1OFF bit is cleared, or if  XT1 is used by ACLK, MCLK, SMCLK or any other peripheral with direct XT1 option, and OSCOFF bit in the processor status register isn't set.

Well, I supposed the following errata needs to be addressed too:

johnw

Well, I supposed the following errata needs to be addressed too:

That's automatically done when you do the recommended testign loop. And if it happens later, after the crystal has stabilized, well, if ou don't enable the fault NMI, it makes no difference and can be ignored.

OK - original question remains unanswered:

Hello All,

Have some questions - from the UG:

XT1 remains disabled until the ports shared with XT1 are configured for XT1 operation. The configuration of the shared I/O is determined by the PSEL bit associated with XIN and the XT1BYPASS bit.

--- Except for the '5635 - XIN and XOUT are dedicated pins 13 and 14.

In the example docs:

P5SEL |= BIT4+BIT5; // Select XT1

Except for the '5635 these are separate pins.

So - what is the correct way to make sure XT1 is enabled for the '5635. I have already piped out ACLK to P1.0 and taken a look - my question is how to do this correctly programmatically that agrees with the available documentation.

Thanks,
johnw

- and - this seems to fix the issue:

Hmmm,

Could this be the magic foo-foo dust:

while(BAKCTL & LOCKIO) // Unlock XT1 pins for operation
BAKCTL &= ~(LOCKIO);

Regards,
johnw

--- those that respond - are you using the '5635? - and - XT1 and XT2 are physically populated?

Thanks,
johnw 

johnw

original question remains unanswered:

No. It was answered. But maybe a bit more detailed answer is necessary.

AS you discovered yourself, the XIN and XOUT pins are dedicated, not shared pin on the 563x. So no port pin configuratonis needed. The pins are always ready for a crystal. Also, the default configuraton of the universal clock system has XT1 oscillator active for a low-frequency crystal. OSCOFF bit is not set. XT1OFF is set by default´and needs to be cleared to enable XT1 even if not (yt) used for anything. However, ACLK is set to XT1 by default, which should override XT1OFF anyway. (see register description of TX1OFF bit).

The datasheet (slas650b.pdf) seems to indicate that XT1 does not support high-frequency mode. At least there is no data for HF mode in the datasheet. It is a bit surprising that XT1 shall not support HF mode, but if it is so, then it is so.
For an HF crystal, use XT2, which is shared with P7.2/P7.3 and requires a port setup as described (P7SEL |= BIT2|BIT3;). Also, XT2OFF bit in UCSCTL6 is set by default, disabling XT2.

So in theory, XT1, if populated with a crystal that matches the default 12pF load setting (can be changed with the XCAPx bits), should work from power-on without software. It is, however, necessary to wait for the crystal to come up (waiting loop according to the users guide). And clearing the XT1OFF bit ensures the crystal doesn't shut down if XT1 is temporarily not used by anyone (e.g. in LPM4) and would require another startup time when reactivated.

johnw

are you using the '5635?

No. But the clock system is almso tidentical for all MSPs of the same family and the few minor differences are documented.

Hello All,

**** - ok - let me try this again:  The following from the UG - does not apply to the '5635 - there's really no question about it:

Have some questions - from the UG:

XT1 remains disabled until the ports shared with XT1 are configured for XT1 operation. The configuration of the shared I/O is determined by the PSEL bit associated with XIN and the XT1BYPASS bit.

--- Except for the '5635 - XIN and XOUT are dedicated pins 13 and 14.

**** - And here - in the example code that is loaded via CCS - does not apply either:

In the example docs:

 P5SEL |= BIT4+BIT5;                       // Select XT1     

Except for the '5635 these are separate pins.

So - what is the correct way to make sure XT1 is enabled for the '5635.  I have already piped out ACLK to P1.0 and taken a look - my question is how to do this correctly programmatically that agrees with the available documentation.

****  Where is LOCKIO discussed?  Not in the UG.

I do find it in the include file: 

/* PM5CTL0 Power Mode 5 Control Bits */
#define LOCKIO LOCKLPM5 /* Lock I/O pin configuration upon entry/exit to/from LPM5 */

Thanks,
johnw 

from the UG:

XT1 remains disabled until the ports shared with XT1 are configured for XT1 operation. The configuration of the shared I/O is determined by the PSEL bit associated with XIN and the XT1BYPASS bit.

Taking it literally, this statement is incorrect. PSEL controls the multiplexing of shared pins, it does not enable/disable XT1. However, if XT1 is not connected to a pair of pins to access an external crystal, XT1 does not work even when enabled.

johnw, you're asking the same question again and again and all you can get is the same answer again and again. This is not a lottery where you get a new number on every turn.

I already told you that on the 5635 no port configutation is neded to allow XT1 operation and that the defaults have it active as soon as the chip is powered.

Al you have to do is to wait for the crystal becoming stable (and perhaps adjus tthe load capacitor selection to fit your crystal). The procedure is in the users guide (loop until you can clear the oscillator fault bits)

johnw

****  Where is LOCKIO discussed?  Not in the UG.

It is. But not in the clock system section. LOCKIO is for locking the I/O pin states durign LPM3.5/4.5 where the MSP is almost completely switched off (including ram retention and clock system).
It is discussed in the power management module PMM) and the section about low-power modes. And since on your MSP XT1 is not multiplexed with a port pin, it is completely unrelated.

OCY,

And - in the '5635 - as a specific example here - PSEL does not apply.  It appears to be a documentation bug in SLAU208K.  I have submitted a bug report to TI on this.

If anyone is interested that is using XTALs on both XT1 and XT2 in this series - I will post a code snippet that is working for me.

Regards,
jwest 

johnw

****  Where is LOCKIO discussed?  Not in the UG.

It is. But not in the clock system section. LOCKIO is for locking the I/O pin states durign LPM3.5/4.5 where the MSP is almost completely switched off (including ram retention and clock system).
It is discussed in the power management module PMM) and the section about low-power modes. And since on your MSP XT1 is not multiplexed with a port pin, it is completely unrelated.

OK - are we taking about the same document?  Can you show me where LOCKIO is in SLAU208K?

Regards,
jwest 

SLAU108k.pdf, Part of page 108, quote:

2.2.7 LPM3.5 and LPM4.5
LPM3.5 and LMP4.5 are additional low-power modes in which the regulator of the PMM is completely
disabled, providing additional power savings. Not all devices support all LPMx.5 modes, so see the
device-specific data sheet. Because there is no power supplied to VCORE during LPMx.5, the CPU and
all digital modules including RAM are unpowered. This disables the entire device and, as a result, the
contents of the registers and RAM are lost. Any essential values should be stored to flash prior to entering
LPMx.5. PMMREGOFF bit is used to disable the regulator. See the SYS module for complete descriptions
and proper uses of LMPx.5.
Because the regulator of the PMM is disabled upon entering LPMx.5, all I/O register configurations are
lost. Therefore, the configuration of I/O pins must be handled differently to ensure that all pins in the
application behave in a controlled manner upon entering and exiting LPMx.5. Properly setting the I/O pins
is critical to achieving the lowest possible power consumption in LPMx.5, as well as preventing any
possible uncontrolled input or output I/O state in the application. The application has complete control of
the I/O pin conditions preventing the possibility of unwanted spurious activity upon entry and exit from
LPMx.5. The I/O pin state is held and locked based on the settings prior to LPMx.5 entry. Upon entry into
LPMx.5, the LOCKLPM5 bit in PM5CTL0 of the PMM module is set automatically. Note that only the pin
condition is retained. All other port configuration register settings are lost. See the Digital I/O chapter for
further details.

Unquote

"LOCKIO" is not spelled out. Another BUG ? (Or the egg  -- nit?)

Actually, BAKCTL register, which you quoted in your question, contains a LOCKBAK bit, not LOCKIO bit. It serves the same purpose for the RTC as the LOCKAUX bit in the AUX module for the auxiliary supply and the LOCKLPM5 bit in the PMM module for the digital IO.

"LOCKIO" was the old name for "LOCKLPM5" bit in PM5CTL0 register and apparently has been renamed in SLAU208f.
So no, we were actually not talking about the same dcument, or at least not about the same revision. Luckily I have copies of some older revisions.
I guess this happened when the former LPM5 was renamed LPMx.5 due to the new RTC_B module which splti the formwe LPM5 into LPM4.5 (no RTC) and LPM3.5 (RTC and XT1 for RTC still active). Sometimes, new features require some nomenclature changes.

However, LOCKIO was never part of BAKCTL, so the code you quoted is, well, simply nonsense. Where did you get if from?

Nevertheless, it has nothing to do at all with XT1 on your MSP, as XT1 has, as you discovered yourself and as I confirmed several times, has its own dedicated pins and therefore has no dependency to the IO pins.

There is a dependency to the Backup system and LOCKBAK, but only if you manually got into LPM3.5 and need XT1 operative even after shutting down the system, to drive the RTC. During normal operation, no LPM3.5 and RTC usage during this LPM, it is on no relevance to XT1 operation too.

 

This has been discussed in a prevoius thread - I didn't find this the first time around - but I think it is good to add the reference to this thread:

http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/185480.aspx

Regards,
johnw