Tool/software:
I will try to explain this problem in as detailed manner as possible.
The system:
A capacitive touch sensor is connected to the MSP430F5505 MCU. The user keeps their finger on the sensor and the sensor does some processing (it has an ASIC in it). When the sensor is ready to send the data, it justs pulls the RDY signal low. The RDY signal is fed as an input to the MCU.
The clock configuration:
There is an external crystal of 4MHz which is used to provide the clock to the MCU. There are three main clocks in the MCU - Main Clock, Sub Main clock and the Alternate Clock. The I2C peripheral takes the clock from Sub Main Clock for it's SCL.
XT2 (4MHz) -> FLL (here we do the multiplication and send the MCLK=SMCLK = 24MHz) -> DCO -> MCLK and SMCLK
Problem:
In the main loop, just as soon as we enter, I have a test code that goes like this:
```
static volatile uint32_t GETmclk = 0;
static volatile uint32_t GETsmclk = 0;
static volatile uint32_t GETaclk = 0;
while (1)
{
__no_operation();
__no_operation();
GETsmclk = UCS_getSMCLK();
GETmclk = UCS_getMCLK();
GETaclk = UCS_getACLK();
__no_operation();
}
```
When I comment the code written in the while loop, the RDY pin starts behaving as if it is floating. The pin is supposed to go LOW only when the user touches the sensor, but the scenario where the code is not commented, the pin goes low even when the user is not touching it.
So I thought : "hey, let me just pull the RDY (the input pin) HIGH" and it worked. Using the software, the enable the pull up pin and it worked. But there is another catch:
When I run the SMCLK using the REFOCLOCK, and the SMCLK is running at a much lower speed, the problem does not occur even when the GPIO pin is not pulled HIGH.
So I thought: let me try reducing the SMCLK when it is being sourced from the DCO. That didn't solve the problem. I wonder what is happening.
Why is reading the SMCLK and MCLK in the main loop helping with the floating PIN? Is it somehow syncronizing the clocks? Why is sourcing the SMLCK from REFOCLOCK helping?
The clock init is like this:
```
static void initClock(void)
{
GPIO_setAsPeripheralModuleFunctionInputPin(GPIO_PORT_P5, GPIO_PIN2 | GPIO_PIN3);
UCS_setExternalClockSource(0, XT2_FREQ);
UCS_turnOnXT2(UCS_XT2_DRIVE_4MHZ_8MHZ);
while (UCSCTL7 & (XT2OFFG | DCOFFG))
{
UCSCTL7 &= ~(XT2OFFG | DCOFFG);
SFRIFG1 &= ~OFIFG;
}
UCS_initClockSignal(UCS_FLLREF, UCS_XT2CLK_SELECT, UCS_CLOCK_DIVIDER_4);
UCS_initFLLSettle(MCLK_KHZ, MCLK_FLLREF_RATIO);
UCS_initClockSignal(UCS_SMCLK, UCS_DCOCLK_SELECT, UCS_CLOCK_DIVIDER_1);
//Since we are not using ACLK, we can disable it.
UCS_disableClockRequest(UCS_ACLK);
// Configure USB PLL
USBKEYPID = 0x9628; // Unlock USB configuration registers
USBPLLDIVB = 0; // Divide XT2 by 1 (XT2 = 4 MHz input to USB PLL)
USBPLLCTL = UPLLEN | UPFDEN; // Enable USB PLL and frequency detector
// Wait for USB PLL to lock
while (USBPLLIR & USBOORIFG);
USBKEYPID = 0x9600; // Lock USB configuration registers
}
#define MHz ((uint32_t)1000000)
#define XT1_FREQ ((uint32_t)32768)
#define XT2_FREQ ((uint32_t)(4*MHz))
#define MCLK_FREQ ((uint32_t)(24*MHz))
#define SMCLK_FREQ ((uint32_t)MCLK_FREQ)
#define XT1_KHZ (XT1_FREQ / 1000)
#define XT2_KHZ (XT2_FREQ / 1000)
#define MCLK_KHZ (MCLK_FREQ / 1000)
#define SCALE_FACTOR ((uint8_t)4)
#define MCLK_FLLREF_RATIO (MCLK_KHZ / (XT2_KHZ / SCALE_FACTOR))
```
The summary would be:
- When the content inside the while (1) is commented out (i.e., the
GETmclk = UCS_getMCLK() and related lines), the RDY line starts
behaving as if it's floating.
- Enabling internal pull-up on RDY stabilizes it and prevents false
triggering.
- Using REFO for SMCLK (instead of DCO @ 24 MHz) also prevents the RDY
from falsely going low, even without a pull-up.
- Reducing the SMCLK frequency while still sourcing it from the DCO
does not solve the problem.
- The act of reading clock values (like UCS_getSMCLK()) inside the
main loop somehow stabilizes the RDY line behavior.
