• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 81 subscribers
  • Views 6787 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP ACLK/XT1 problem

jrg
Prodigy 20 points
Other Parts Discussed in Thread: MSP430WARE

I have run into what appears to be a hardware problem with the 80-pin "XMS430F5438" chips. I am sourcing ACLK from XT1 which is using a 32.768KHz crystal. Instead I am seeing an ACLK frequency of about 30.6KHz. This is observed from the RTC period and from the async baud rate, both of which are driven from ACLK.

I originally had this running on the MSP-TS430PZ5x100 eval board using the crystal supplied with the board.. The ACLK frequency was correct. I am now running the same code on a board using the 80-pin chip (which is still labeled X430F5438 and which identifies itself as an XMS430F5438) and I am getting the incorrect ACLK frequency.

1) I am using the same crystal that was used on the eval board. (I removed it from the eval board and moved it to the new board.). I initially used another crystal which I believe was a 32.768 crystal with the same results.
2) I have loaded exactly the same code image into the two chips. The 100-pin chip on the eval board gives the correct ACLK frequency, the 80-pin chip does not.
3) I've tried this on two different 80-pin chips with the same results on each.
4) I have observed a sine wave on the crystal. As best as I can measure the frequency with my scope, is slightly less than 33KHz, so it appears to be oscillating at the correct frequency.
5) I also thought there might be something funny about the ACLK selection, so I tried changing it first to use VLO and then REFO. In both cases, the behavior was as expected. Neither resulted in a correct 32.678KHz ACLK. It is interesting that selecting REFO gave exactly the same ACLK rate as did selecting XT1. This would tend to imply that XT1 is not working and REFO is being automatically used instead. This is reinforced by the fact that the XT1LFOFFG bit in UCSCTL7 is set every time I look at it after a reset. If I clear it, it stays cleared and the frequency stays the same.

  • 0
    TI__Genius 16165 points

    The proper way of testing your ACLk is by probing the ACLK pin itself.

    First, try outputting the ACLK to P2.6/ACLK pin (80-pin) and probe it with an oscope and observe the frequency.
    I am attaching a code here that will initialize the crystal and outputs ACLK to Pin 33.
    This code works only for 80 pin as ACLK is assigned to that pin.

      
      P2DIR = BIT6;                             // P2.6 to output direction
  P2SEL = BIT6;                             // P2.6 to output ACLK                                          
  P7SEL |= 0x03;                           // Port select XT1 

  UCSCTL6 &= ~(XT1OFF);            // Switch XT1 On
  
  // Loop until XT1,XT2 & DCO stabilizes
  do
  {    
    UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + DCOFFG);
                                                    // Clear XT2,XT1,DCO fault flags
    SFRIFG1 &= ~OFIFG;               // Clear fault flags
    for(i=0;i<0xFF;i++);                 // Delay for Osc to stabilize
  }while (SFRIFG1&OFIFG);           // Test oscillator fault flag 

  UCSCTL4 |= SELA_0                    //Select ACLK = LFXT1
  • 0 in reply to William Goh
    Prodigy 20 points

    Thank you for the information, which did solve my problem. Measuring the ACLK frequency however, was not the issue.

    Simply looking at ACLK on pin 33 showed exactly what I expected, which was about 30.5KHz. The problem was that I was

    not delaying until the oscillator was stable before selecting XT1. Strangely, this did not prevent selecting XT1

    with the 100-pin part on the eval board. It must have been right on the edge of not working. Adding the code to

    delay until the oscillators are stable resulted in a measured ACLK of 32.7654 which is about as close as I would

    expect with my logic analyzer with its 20ns resolution.


     

  • 0 in reply to jrg
    TI__Guru 50741 points

    jrg said:
    Strangely, this did not prevent selecting XT1

    Just to add a little more clarification here. There is nothing that prevents you from setting bits to select a certain clock source such as XT1 for ACLK (or another internal clock tree). However the clock system's fault detection logic monitors the various clock sources in the system, and overrides your setup in case a fault is detected. For example, a 32.768kHz XTAL that is just starting up causes an oscillator fault condition (setting XT1LFOFFG), which itself will activate the internal REFO oscillator (~32kHz, see device datasheet), which will take over to clock ACLK. This is why there still was a clock in your original case.... For more details please refer to the "Unified Clock System Module Fail-Safe Operation" section in the 5xx Family User's Guide.

  • 0 in reply to Andreas Dannenberg
    Guru 14640 points

    If I read these posts correctly, I think that there is added delay between the "Port select XT1" and "Switch XT1 On" to allow the oscillator to stabilize before using, correct?

    On the F5529, the XT1 is defaulted to "on" on powerup. Does that mean it should be turned off, then allowed to stablize, then turned on?

    I also need to set up XCAP to be different that default. So, should I

    1. Turn off XT1.

    2. Port select Xt1.

    3. Wait for stabilization.

    4. Turn on XT1.

    5. Then route to RTC, ACLK and any other place it is being used.

  • 0 in reply to Todd Anderson78572
    Guru 25210 points

    I think you want to follow the recommendations in the User's Guide and the MSP430Ware examples for 5xx USC. At startup, change your XCAP, select the XT1 input and do the fault-clearing loop thing until the fault flags go away.

**Attention** This is a public forum