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.

Wolverine crystal calibration - ACLK at wrong freq

Other Parts Discussed in Thread: MSP-TS430RGZ48C, CC1120, MSP430FR5969

Has anyone used the clock system on the new Wolverine sample chip?  I have got my MCLK / SMCLK running at 8 MHz successfully, but the crystal for ACLK appears to be running at 38.4 kHz on my oscilloscope.  I am not sure whether is my soldering job or the code that is the problem.  I put two 10pF capacitors on the MSP-TS430RGZ48C at C1 and C2 but that didn't make any difference.  The crystal is on Q1.

#include <msp430.h>

/*
 * Example program for MSP430FR5969 with 32768 Hz Crystal attached.
 * Runs at ~8 MHz MCLK/SMCLK and 32768 Hz ACLK
 */

void main()
{
    /*
     * Clock setup
     */
    WDTCTL = WDTPW | WDTHOLD;        // Watchdog off
    PJSEL0 |= BIT4 | BIT5;           // Crystal mode for PJ.4 and .5
    CSCTL0 = CSKEY;                  // Unlock clock registers
    CSCTL1 = BIT2 | BIT3;            // 8 MHz DCO (8 MHz is FRAM speed limit)
    CSCTL3 = 0;                      // No dividers
    CSCTL4 = BIT3 | BIT4;            // Disable VLO, LXFTBYPASS on (external pin), lower "drives"
    CSCTL0_H = 0xFF;                // Lock clock registers

    /*
     * Test points for clock frequency
     */
    P2DIR |= BIT0; P2SEL0 |= BIT0; P2SEL1 |= BIT0; // ACLK on P2.0
    P3DIR |= BIT4; P3SEL1 |= BIT4;                 // SMCLK on P3.4

    /*
     * Enable onboard LED
     */
    P1OUT |= BIT0;
    P1DIR |= BIT0;

    while (1)
        ;
}


  • Matthew Cashdollar said:
        CSCTL1 = BIT2 | BIT3;            // 8 MHz DCO (8 MHz is FRAM speed limit)

    On highe rclock, teh controlelr will insert a waitstate, so if you go for 16MHz, you'll still be faster, even though not twice as fast, because all clock cycles that are used for ram or hardware register access are done twice as fast, including push/pop instructions on the stack (if the stack is on SRAM).

  • Matthew Cashdollar said:
    I have got my MCLK / SMCLK running at 8 MHz successfully, but the crystal for ACLK appears to be running at 38.4 kHz on my oscilloscope.

    The code sets the LXFTBYPASS bit, which configures operation for an external clock on the LFXIN pin (PJ.4), rather than a crystal across the LFXIN and LFXOUT   (PJ.4 / PJ.5) pins. Do you want to use an external clock input or an external crystal?

    Also, the software needs to set the PJSEL0.4 bit to enable PJ.4 and PJ.5 to operate as LFX pins rather than I/O

  • Matthew Cashdollar said:

    Has anyone used the clock system on the new Wolverine sample chip?  I have got my MCLK / SMCLK running at 8 MHz successfully, but the crystal for ACLK appears to be running at 38.4 kHz on my oscilloscope.  I am not sure whether is my soldering job or the code that is the problem.  I put two 10pF capacitors on the MSP-TS430RGZ48C at C1 and C2 but that didn't make any difference.  The crystal is on Q1.

    Hi Matthew,

    please try your modificated code below. P2.0 should now output the 32.7kHz. Nevertheless, you should not use BITxy to configure the registers, rather use the defines for the bits that come with the uC inlude-file.

    WDTCTL = WDTPW | WDTHOLD;        // Watchdog off   
    PJSEL0 = BIT4;                   // Crystal mode for PJ.4 and .5
    PJSEL1 &= ~BIT5;
    CSCTL0 = CSKEY;                  // Unlock clock registers   
    CSCTL1 = BIT2 | BIT3;            // 8 MHz DCO (8 MHz is FRAM speed limit)   
    CSCTL3 = 0;                      // No dividers   
    CSCTL4 = HFXTOFF | LFXTDRIVE_3;
    do {  
    CSCTL5 &= ~LFXTOFFG;  
    SFRIFG1 &= ~OFIFG;
    } while (SFRIFG1 & OFIFG);   // Check oscillator fault
    P2DIR |= BIT0; P2SEL0 |= BIT0; P2SEL1 |= BIT0; // ACLK on P2.0   
    P3DIR |= BIT4; P3SEL1 |= BIT4;                 // SMCLK on P3.4    /*     * Enable onboard LED     */   
    P1OUT |= BIT0;    P1DIR |= BIT0;   
    while (1);

     

  • It is still running at 38.5 KHz on the output at P2.0 with that code (same problem as I had before).  Maybe I damaged the board with my soldering or something...

  • With this code I've measured the correct 32 kHz at my board.

  • Matthew Cashdollar said:
    It is still running at 38.5 KHz on the output at P2.0 with that code

    Are your sure your crystal is 32768Hz (watch crystal)? Maybe you got a 38400Hz crystal (UART crystal for 19200Bd and less). Those are also used as reference for UART-friendly DCO clock setting using the FLL feature of 4x and 5x family.

  • Hi, I exeprimented same issue on two different MPS430FR5969.

    External square wave at 32KHz on LFXIN.

    ACLK runs at 38.5KHz.

    I output a timerA trigger on a digital port and I measured the wrong frequency.

    I'm very surprised! How could it do that? There's no mutiplier onboard.

    My config follows:

        //PJ: 11101111
        //BIT4, IN, LFXIN
        PJDIR = 0xEF;
        PJOUT = 0x0;

        //PJ4 as LFXIN
        PJSEL0 |= BIT4;
        PJSEL1 &= ~BIT4;

        //CS settings
        CSCTL0_H = 0xA5;
        CSCTL1 = DCOFSEL_3; // Set DCO = 4MHz
        CSCTL2 = SELA__LFXTCLK + SELS__DCOCLK + SELM__DCOCLK;
        CSCTL3 = DIVA__1 + DIVS__1 + DIVM__1;
        CSCTL4 = LFXTBYPASS | HFXTOFF;
        CSCTL5 &= ~(LFXTOFFG | HFXTOFFG);
        CSCTL0_H = 0x0;

    Hope someone could help.

    Best regards

    Filippo

  • UPDATE:

    ACLK runs at 38.5 KHz even if I either remove or modify the 32KHz square wave signal on LFXIN.

  • Hi Filippo,

    To me it sounds like maybe you are running into the fail-safe logic on the CS module. When ACLK detects a failure on its clock source, it will automatically switch to LFMODCLK (see the user's guide section 3.2.8 CS Module Fail-Safe Operation). LFMODCLK is MODCLK divided by 128 - the typical MODCLK value is 5MHz, and 5000kHz/128 = ~39kHz, which sounds like what you are seeing (especially since there is a range MODCLK can vary within from part to part - see datasheet). If ACLK is really being sourced by this, it makes sense that you see that same frequency even if you completely remove the signal on LFXIN.

    Try rearranging your code to wait until after you have setup LFXIN and the fault flags have cleared before setting ACLK to be sourced by LFXIN, and see if this makes a difference.

    Regards,

    Katie

     

  • Hi Katie,

    you are right about the fail-safe logic.

    Looking at wolverine code examples and specifically to msp430fr59xx_CS_05.c, ACLK is sourced before LFXIN become stable.

    Anyway I tried and CS module still remain in fail-safe condition.

    I noticed that the very big difference is in the physical 32Khz source. I have a CC1120 rf module on my PCB which could be used a stable clock generator, yes I want to not install 32Khz crystal to save space on pcb and costs.

    When the source is a stable square instrumental generated signal, CS enters and exits to and from fail safe condition without problem when the source is switched on and off.

    When the source is a 32KHz CC1120 generated signal CS exits from fail safe condition for a very small time and then enters again and remains in fail safe.

    So I need to investigate more the issue.

    Anyway any suggestion is appreciated.

    Thank you

    Regards

    Filippo

  • Hi Filippo,

    So it sounds like you have no issue if you use a lab clock generator as your source, but only have an issue when trying to use a 32kHz signal generated from a CC1120? Can you elaborate more on the connection of your CC1120 and how you are creating this 32kHz signal that you are then providing to the MSP430?

    Regards,

    Katie

  • Thank you Katie,

    you're right again. Non issues when using either lab clock generator or crystal quartz.

    About CC120 I'm setting CC112X_IOCFG0 register to 0x36, so I force CC1120 to output the square wave on GPIO0.

    Once radio registers are set, I wait for fault flag off on CS. Fault flag goes off and then return to on.

    CC1120 GPIO0 is connected to LFXIN so to have clock in.

    CC1120 32KHz clock is generated by RC oscillator, so it has to be calibrated continuously by embedded radio chip logic.

    Looking at 32Khz signal I notice some jitter on wave period, even if that signal is very stable and good enough for my needs.

    My guess, but it has to be further verified, is that the jitter, even when slight, could be critical for CS.

    Now, because I need to bypass the problem, I'm testing a different solution. 32Khz clock from radio chip is sourcing directly a timer, which in turn calibrate the VLOCLK every second. I don't expect sudden huge variations on VLOCLK, so it should work fine.

    I'm used to REFO on CC430, and I really miss it on new wolverine mcus.

    Thank you for the support.

  • Filippo Guerzoni said:
    My guess, but it has to be further verified, is that the jitter, even when slight, could be critical for CS.

    It shouldn't. The fault detection is more or less a retriggerable monoflop with a timeout of some 100µs. So it fires when you miss some clock cycles, but not on jitter.

    Is it possible that (e.,g. for low-power mode or something like that) the CC120 temporarily deactivates its output?

    Or do you something that reconfigures your XIN port pin (don't know whether this is possible at all on this MSP).

    Note that the fault flags do not auto-clear when the fault condition is gone. Also, before you can clear it, a certain number of consecutive 'good' clock cycles need to pass first. (before 5x family, you had to clear it and then wait whether it would come up again, on later clock modules, if it clears, you can immediately proceed).
    If the RC calibration process causes the output to cease (or stretch below 10kHz) once every 1024 clock cycles (at least that's the count threshold on 5x family), the fault flag will refuse to be cleared.

  • Thank you Jens-Michael,

    I think I need to investigate further. I'll update the thread when I'll get something new.

    Jens-Michael Gross said:
    Is it possible that (e.,g. for low-power mode or something like that) the CC120 temporarily deactivates its output?

    RC oscillator is forced to be active by setting WOR_CFG0.RC_PD = 0 registry on CC1120 and WakeOnRadio mechanism is fully functional. Clock signal is stable on the line at any moment I test it.

    Jens-Michael Gross said:
    Or do you something that reconfigures your XIN port pin (don't know whether this is possible at all on this MSP).

    I'll search for BOR events, XIN is initially configured as digital IO and then updated to work as LFXIN.

    Jens-Michael Gross said:
    Note that the fault flags do not auto-clear when the fault condition is gone.

    I implemented same check cycle algorithm available from example msp430fr59xx_CS_5.c and it works for external lab generated clock.

    Regards

    Filippo

  • Finally it worked.

    Initial issue.

    Jens-Michael Gross said:
    Note that the fault flags do not auto-clear when the fault condition is gone

    as Katie and Jens-Michael pointed out, fault flags shall be cleared and re-checked to test if fault condition is gone. If not, ACLK runs at 38.5Khz fail safe frequency.

    The issue.

    The fault condition test cycle I copied from wolverine msp430fr59xx_CS_05.c example was quite blocking and I put it too early in the initialization code. So radio startup was critical and 32Khz clock was not stable or generated at all.

    The solution

    Put the fault condition test logic at the very end of initialization code.

    Let the fault condition logic to be non blocking. I used a 100hz ticker timer interrupt logic to test every time the fault condition and eventually reset it.

    So I used no blocking test cycle at all.

    This solution proved to be very stable.

    Thank you for support.

    Regards

  • I am having the same issue with a MSP430FR5969 chip on the MSP-TS430RGZ48C board.

    Using the same target board, I changed the initial 32kHz crystal and FR5969 chip and got the same result. I even consulted the TI SLAA322B document to make sure that i was loading the 32kHz crystal properly.

    Next, I copied and pasted SHau's code (except I have the LED on the MSP-TS430RGZ48C board toggle after the fault condition clears) but I still saw ~38.4kHz square wave on P2.0

    Based on when the LED starts to toggle, it appears that the fault condition clears after a couple tens of seconds - that's really long I know, but that is what I observe. After the LED starts to toggle I pause the code and look in the CS registers and see that LFXTOFFG = 1. Whenever LFXTOFFG or HFXTOFFG = 1, that sets OFIFG in the SF registers. I was thinking about ignoring the 32kHz crystal then do a fault check using OFIFG before using a 16MHz oscillator for MCLK and SMCLK but I cannot do that because LFXTOFFG refuses to clear. 

    I have written a few other codes where I just use the DCO (which works perfectly) but when I pause the code and look in the CS registers, LFXTOFFG is still set. In those codes, I make sure that LFXTCLK is never selected and I initialize, LFXTOFF = 1 and CSCTL5 = 0x0000 only to later see LFXTOFFG = 1 when I pause the code.

    I could do a fault check with just HFXTOFFG but I wanted to chime in this discussion since I was having the same exact issue.

    I hope I provided a bit more info on the problem. What could be some other causes?

  • You should remove LFXTBYPASS because if set the oscillator associated with LFXT is powered down.

    Pag. 79 of MSP430FR5969 userguide.

    Regards

    Filippo

  • LFXTBYPASS = 0, and has always been when I was trying to get the 32kHz crystal to work. I verified that every time by pausing the code and looking in my CS registers. However, LFXTOFFG still does not clear even when I configure the clock system to not use an external source for ACLK.

  • Di you try example code msp430fr59xx_cs_03.c from wolverine example suite?

    Very simple and effective. It worked for me and no need to stop executing code.

    See attached file.

    Regards

    Filippo

  • I just did (and outputed ACLK on P2.0) and the LED keeps blinking, indicating that a fault conditions happens over and over. On my scope I see a quick flashes of another square wave at a different frequency and duty cycle, as opposed to only the ~38kHz square wave.

    I was able to capture just one sample of that wave and it is a 32kHz square wave with a ~25% duty cycle. The line of code below

    CSCTL4 |= LFXTDRIVE_0;

    in the file you attached, does not set the lowest drive strength. It does the equivalent of this (11 | 00 = 11) for the two relevant bits. So the drive strength is actually its highest, not the lowest. This can also be seen if that sample code is paused and you look in the CS registers. The MSP430FR5969 errata (SLAZ473B) states:

    XOSC11 XOSC Module
    Function             LFXT oscillator duty cycle not stable at the highest drive strength setting
    Description        When the low frequency crystal oscillator (LFXT) is set to the highest drive strength setting (CSCTL4.LFXTDRIVE = 11) the duty cycle may be unstable causing the LFXT to not start up or function as expected.
    Workaround       None. Use the lower drive strength settings.

    As a result, I lowered my drive strength but the brief 32kHz flashes seem to have disappeared. I only see the 38kHz now. I put a breakpoint in the code to check whether it's even entering the fault interrupt and my breakpoint is never reached! 

    I am trying to figure out what is causing this problem. The MSP-TS430RGZ48C board, the chip or something else? I will post updates as I try and discover new things.

  • Jamesy Jean-Michel said:
    I was able to capture just one sample of that wave and it is a 32kHz square wave with a ~25% duty cycle.

    This looks liek a mismatched load capacitance or a physically damaged crystal. Normally, oscillation should be ~50% DC, while the amplitude determines whether oscillation is detected or not. An asymmetrical duty cycle indicates a major distortion in the oscillator symmetry.

    How do you measure? If oyu use a standard scope probe on an oscillator pin you're lucky you got some oscillations sometimes. These probes have so much input capacitance that observing a crystal is virtually impossible.
    We bought a ~$800 active FET probe with 0.9pF input capacitance for this task.

    Or did you put the scope on the ACLK output?  Again, DC should be ~50%. If not, the crystal isn't symmetrically running.

    One wild speculation: What if your code resets periodically? Do you see any dropouts on the ACLK output? Maybe the MSP is resetting, fallign back to 38kHz, then the crystla is coming up but then it resets again and falls back to 38kHz and so on.

  • It's possible that the crystal is damaged, I can put in a third one and see what happens.

    I don't think the load capacitance is mismatched too much. Before I put in the second 32kHz crystal to replace the initial one, I read TIs "slaa322b" and chose load capacitors C1 = C2 on the MSP-TS430RGZ48C board. I then used an LRC meter to measure C1 and C2 - while the FR5969 chip was removed from the socket and the 2nd crystal was not yet soldered. I did it that way so I could include the parasitic capacitances of the dev board in my measurement. I measured ~29pF for both C1 and C2. If we round and say C1 = C2 = 29pF, then CL = 14.5pF for a 32kHz crystal specified for a load capacitance of 12.5pF. Would a 2pF measured difference cause what I am seeing?

    I use a standard 10Mohm, 12pF, 500MHz, 10:1 probe with a 500MHz lecroy waverunner scope on the ACLK output (P2.0)

    From my previous post, I was using the sample code "msp430fr59xx_CS_03.c" which I modified so it would output ACLK on P2.0 so I can measure it with a scope. As far as I can tell, that code should not reset. The chip is instructed to go to LPM0 and wait for a fault flag to do something. I do not see any dropouts on the ACLK output (or if there are any they are happening too fast to see with the naked eye). I do not see any dropouts on the JTAG's VCC supply which the board is using either.

  • Jamesy Jean-Michel said:
    Would a 2pF measured difference cause what I am seeing?

    Add another 1pF load for the 2*2pF pin capacitance of the MSP. However, 3pF symmetrically applied would only detune the crystal. To cause an assymmetrical duty cycle of 25%, one side must be loaded significantly different than the other. Perhaps not by capacitive but by resistive load. Or there is a significant offset voltage on these pins in additon to the oscillation's average (mean) voltage.

    Jamesy Jean-Michel said:
    I do not see any dropouts on the ACLK output (or if there are any they are happening too fast to see with the naked eye)

    If the device would reset, there would be a dropout ont he ACLK output for the time where the boot code resets the pin function to the moment you (re)activate ACLK output. However, since one ALCK cycle is 30µs, this could pass unnoticed.

**Attention** This is a public forum