This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP432P401R: External Crystal Is Not Driving MCU at correct Frequency

Part Number: MSP432P401R
Other Parts Discussed in Thread: MSP-FET

Hi, 

I have a custom PCB with an MSP432P401R and an MSP432 Launchpad. I'm trying to drive my custom design with a 48MHz external crystal. I created two blank projects in CSS, one for the Launchpad and one for the custom board. I've used the example code from TI to switch the Launchpad from using the DCO to using the 48 MHz crystal. When I copy/paste the example code to drive the MCU with the 48 MHz crystal into the project for the custom board, compile, download to the device, and look at the output pin for the MCLK the frequency is 16 MHz instead of 48 MHz. I'm copying/pasting only the .c example, not the entire example project, so there may be some slight differences in the startup_*.c code based on the version of CSS the examples were created with?

The Launchpad has an MSP432P401R Rev C and my custom board has an MSP432P401R Rev D.

I've checked the part number of the crystal to make sure it's 48 MHz. Since I'm copying/pasting the code, there are no software differences. The only differences between the two configurations are the debugger (XDS on the Launchpad vs. MSP430 in the MSP-FET) and the actual part number of the crystal, but both are at 48 MHz.

The crystal on my custom board is an Abracon ABLS-48.000MHZ-B2-T with 22pf caps to ground, connected across pins PJ.2 and PJ.3.

I've also used the debugger to check the register value of the CS clock dividers and all the dividers are set to zero, so the HFXTCLK shouldn't be divided before sourcing MCLK. 

Not sure what the next thing to look at should be.

Thanks for any help!

Here's the example code that I've been using:

#include "ti/devices/msp432p4xx/inc/msp.h"
#include "stdint.h"

void error(void);

int main(void)
{
    volatile uint32_t i;
    uint32_t currentPowerState;

    WDT_A->CTL = WDT_A_CTL_PW |             // Stop WDT
                 WDT_A_CTL_HOLD;

    P1->DIR |= BIT0;

    /* NOTE: This example assumes the default power state is AM0_LDO.
     * Refer to  msp432p401x_pcm_0x code examples for more complete PCM operations
     * to exercise various power state transitions between active modes.
     */

    /* Step 1: Transition to VCORE Level 1: AM0_LDO --> AM1_LDO */

    /* Get current power state, if it's not AM0_LDO, error out */
    currentPowerState = PCM->CTL0 & PCM_CTL0_CPM_MASK;
    if (currentPowerState != PCM_CTL0_CPM_0)
        error();

    while ((PCM->CTL1 & PCM_CTL1_PMR_BUSY));
    PCM->CTL0 = PCM_CTL0_KEY_VAL | PCM_CTL0_AMR_1;
    while ((PCM->CTL1 & PCM_CTL1_PMR_BUSY));
    if (PCM->IFG & PCM_IFG_AM_INVALID_TR_IFG)
        error();                            // Error if transition was not successful
    if ((PCM->CTL0 & PCM_CTL0_CPM_MASK) != PCM_CTL0_CPM_1)
        error();                            // Error if device is not in AM1_LDO mode

    /* Step 2: Configure Flash wait-state to 1 for both banks 0 & 1 */
    FLCTL->BANK0_RDCTL = (FLCTL->BANK0_RDCTL & ~(FLCTL_BANK0_RDCTL_WAIT_MASK)) |
            FLCTL_BANK0_RDCTL_WAIT_1;
    FLCTL->BANK1_RDCTL = (FLCTL->BANK0_RDCTL & ~(FLCTL_BANK1_RDCTL_WAIT_MASK)) |
            FLCTL_BANK1_RDCTL_WAIT_1 ;

    /* Step 3: Configure HFXT to use 48MHz crystal, source to MCLK & HSMCLK*/


    PJ->SEL0 |= BIT2 | BIT3;                // Configure PJ.2/3 for HFXT function
    PJ->SEL1 &= ~(BIT2 | BIT3);

    CS->KEY = CS_KEY_VAL ;                  // Unlock CS module for register access
    CS->CTL2 |= CS_CTL2_HFXT_EN | CS_CTL2_HFXTFREQ_6 | CS_CTL2_HFXTDRIVE;
    while(CS->IFG & CS_IFG_HFXTIFG)
        CS->CLRIFG |= CS_CLRIFG_CLR_HFXTIFG;

    /* Select MCLK & HSMCLK = HFXT, no divider */
    CS->CTL1 = CS->CTL1 & ~(CS_CTL1_SELM_MASK | CS_CTL1_DIVM_MASK | CS_CTL1_SELS_MASK | CS_CTL1_DIVHS_MASK) |
            CS_CTL1_SELM__HFXTCLK | CS_CTL1_SELS__HFXTCLK;

    CS->KEY = 0;                            // Lock CS module from unintended accesses

    /* Step 4: Output MCLK to port pin to demonstrate 48MHz operation */
    P4->DIR |= BIT3 | BIT4;
    P4->SEL0 |=BIT3 | BIT4;                 // Output MCLK
    P4->SEL1 &= ~(BIT3 | BIT4);

    while (1)                               // continuous loop
    {
        P1->OUT ^= BIT0;                    // Blink P1.0 LED
        for (i = 200000; i > 0; i--);       // Delay
    }
}

void error(void)
{
    volatile uint32_t i;

    while (1)
    {
        P1->OUT ^= BIT0;
        for(i = 20000; i> 0; i--);          // Blink LED forever
    }
}

  • Hey James,

    Thanks for making a new thread for this question! Something about this makes me think it's related to hardware or layout and not the code itself if you are getting this same code to work on the launchpad and not your custom board. The revision differences between Rev C and Rev D should not impact this so I believe we can rule that out for now.

    Is there any chance you can send a schematic and layout snapshot of your crystal on your custom board?
  • A few recommendations for hardware layout as well for this:

    Make sure your HFTX lines are not near any other high frequency signals. Make sure that you have a ground plane underneath the crystal oscillator and lines if possible. Do not send the HFXT lines through vias. Make sure you are accounting for the load capacitance of the lines.

    Also, I noticed that the load capacitance of your crystal is 18pF likely? Can you confirm this?

    If your load capacitance is 18pf, could you try using 30pf capacitors for C1 and C2 to ground?

    I calculated this from the following:

    This is found in the E4 Systems Design Guidelines handbook, but more generally is applicable to any crystal layout. 

  • Hi Evan!

    I agree that it's probably not the code. The board is fairly simple: 4 layers(2 signal, power, and gnd).

    Above are screenshots of the schematic and layout for the oscillator. Let me know if something you're interested in isn't included in them.

    Thanks!

    -James

  • James,

    Please let me know what you think about trying out in the post just above yours. I'd be interested to know if you calculated your own C1 and C2 values for caps to ground or if you just used the standard 22pF that we have on the LaunchPads. These caps are dependent on the load capacitance of your crystal and this may require some tuning.
  • Yes, I used 22pF load caps instead of 18pF so that'll be changed for Rev 2, but it's hard to believe that a variation in load capacitance would cause an exact divide by 4 in the oscillator frequency.
  • The 22pF load caps were pulled from another design using this same oscillator but with a different microprocessor, but there's a chance that they ran into a similar issue and had to tune the caps a bit but the changes didn't make it into the schematic.
  • James,

    Maybe I should have been more clear, my apologies, but I think that your C24 and C25 need to be 30pF. I agree that it's odd that this would cause an exact divide by 4, but this is my first course of action. The equation I noted above is the calculation for C24 and C25 (just meantioned C1 and C2 since they were in the equation). This is all based on the 18pF load capacitance of your crystal itself to my understanding after looking at it's datasheet. I'd be interested to know if your other group had to tune the caps further. Please let me know!
  • I had 27pF and 33pF caps, so I used 27pF and the frequency on the MCLK pin is still 16 MHz. I'm replacing the crystal next. Maybe Abracon put a 16MHz crystal in a 48 MHz package...
  • James,

    That's strange. I would definitely reach out to Abracon and ask. If you try replacing the crystal, you might look at the KX-7T 48MHz 12pF. We use this on our LaunchPad. Could be good to see if this resolves the issue.
    www.geyer-electronic.de/.../GEYER-KX-7.pdf
  • Right now, I'll have to stick with the same footprint, but I'll definitely take a look at the KX-7T going forward.
  • Sounds good, let me know if you have any updates or want me to look further into something. Thanks!
  • Evan,

    I think I stumbled onto the problem. The crystal I chose is a third overtone crystal which probably accounts for the divide by 3 I'm seeing to get 16 MHz. I'm doing some reading through Abracon app notes to learn more about it.

    -James
  • James,

    Thanks for letting me know. Should we consider this thread closed then or do we need to look into anything else?

  • Closed. I was just making sure that I was accounting for everything on the MSP side of things to make sure I wasn't making a stupid mistake. Turns out it was just a bad part selection.

    Thanks!

  • Gotcha! Happy holidays and feel free to come back with any other questions! I was happy to help make sure it wasn't an error on our end!

**Attention** This is a public forum