• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 585 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430FR2675: DriverLib Clock Initialization

Ryan Schuh
Prodigy 90 points
Part Number: MSP430FR2675


Hi, 

I am working on fixing an issue that we are seeing in manufacturing and believe I have found a bug in the driver library for the MSP430FE2xx_4xx parts; version: 2.91.13.01. 

We are seeing an issue when we set the clock up with CS_initFLLCalculateTrim(3000, 3000/34, stuct). The 34 was previously 32 and this worked with our prototypes, when we got to production we saw some issues with some parts not getting through the clock init and based on feedback from a TI FAE(I can't find the emails), we changed to 34 and that worked for awhile and now we are seeing the same issue.  

I can get it working again if I increase the divider from 34 to 35 but while troubleshooting, I realized that the loop in the CS_initFLLCalculateTrim appears to track the best setup but will loop continuously until it is inside the values set if it isn't within the defined range.  

I was hoping to talk with an FAE about this and see if there is a possible bug in the library or something.  

 

Thanks, 

Ryan 

  • 0
    TI__Genius 10060 points

    Hi Ryan,

    What do you believe to be the bug in driverlib? As far as I see, the second parameter just delays the return of the function so the oscillator fault doesn't fire before the clock has stabilized. 

    Ryan Schuh said:
    I can get it working again if I increase the divider from 34 to 35 but while troubleshooting, I realized that the loop in the CS_initFLLCalculateTrim appears to track the best setup but will loop continuously until it is inside the values set if it isn't within the defined range.  

    Your statement above is confusing me. There are two locations in CS_initFLLCalculateTrim where the code waits. 1) Makes sure the oscillator faults are clear 2) wait the a specific delay before re-enabling the interrupt. Are you getting stuck in 1)? 3000/34 and 3000/35 will affect 2) but shouldn't affect 1). 

    Can you review the driverlib example cs_ex1_DCO1MHzSWTrim and see if there are any difference between your code and the example? 

    How did you come to 3000/34 for the second argument? The example uses 30.

    Regards,

    Evan

  • 0 in reply to Evan Lew
    Prodigy 90 points

    Sorry, I got grabbed the wrong function name, its actually getting stuck in the do-while loop in privateCSComputeDCOFTrim.  

    The bug I think is that it can get stuck in that do-while if it never hits the targets that are set rather than kicking from the loop after X cycles or something.  For testing, I added a count and kick it from that do-while after 24 cycles and it seems to work well on the one unit I am testing on currently.  

    I came to 3000/34; originally I used 3000/33, as I understood the ratio to be target kHz/FLL kHz (32.768 kHz) so I rounded the kHz and set the code up to allow clock speed adjustments to be 1 number change and do the math rather than divide it out outside the code.   

    The move to /34 was made after talking to an FAE previously about the same thing happening and this was the suggested fix.  

    The rest of my clock setup matches the example very closely.  

    Ryan 

  • 0 in reply to Ryan Schuh
    TI__Genius 10060 points

    Do you know where in privateCSCompteDCOFTrim(..) you application is getting stuck? There are two places where the code waits for a flag inside this function.

    What frequency are you trying to lock to? 

    Also, please make sure you review the MSP430FR2xx/FR4xx DCO+FLL Applications Guide section 4 which specifically discusses ways to lock the FLL quickly. 

    Regards,

    Evan

  • 0 in reply to Evan Lew
    Prodigy 90 points

    It is getting stuck in the second do-while where it checks the different DCO taps to find a fit. I don't have the line numbers in front of me but it just never falls perfectly in the range so it continues to loop rather than picking the "best" fit and moving on.  

    I am trying to lock to 3MHz.  

    I have looked at that guide a lot.  I will look it over again and see if I missed anything. 

  • 0 in reply to Ryan Schuh
    TI__Genius 10060 points

    Thanks for the update Ryan.

    I'm still trying to make sense of something you said earlier: 

    Ryan Schuh said:
    I can get it working again if I increase the divider from 34 to 35 but while troubleshootin

    Changing this ^ value only affects the wait time after privateCSCompteDCOFTrim() is called. I don't see how changing this value would affect whether or not you are getting stuck in privateCSCompteDCOFTrim().

    How did you confirm you are stuck in privateCSCompteDCOFTrim()?

    Evan

  • 0 in reply to Evan Lew
    Prodigy 90 points

    I confirmed with the debugger where the code was getting stuck as well as using leds on/off to signal the function it is in when it locks up. 

    I agree that it doesn't look like it should matter, but one of the registers being set in the privateCSComputeDCOFTrim call using the ratio must be effecting the viability of making it through that loop.  

  • 0 in reply to Ryan Schuh
    TI__Genius 10060 points

    Understood. Thanks for confirming, I will get back to you tomorrow.

  • 0 in reply to Evan Lew
    Prodigy 90 points

    I thought of one additional thing to point out, this seems to be a part to part issue.  There are a high % of our boards that are working fine with the current setup.  We are seeing some where in the 20% range fail given this setup.  

  • +1 in reply to Ryan Schuh
    TI__Genius 10060 points

    Ryan,

    Thanks for the info and your patience. 

    Since you are trying to lock to the set the DCO to an "in between" frequency (ohter than the 1,2,4,8,12MHz, etc) you need to follow the example code referenced in MSP430FR2xx/FR4xx DCO+FLL Applications Guide (download here: MSP430FR2xx/FR4xx DCO+FLL Code Examples) 

    The driverlib code doesn't cover this approach as far as I know. I made a small modification to the example to make it run a 3MHz and I was able to see it work.

    Please try this method in your system and report back your findings.

    Regards,

    Evan

  • +1 in reply to Evan Lew
    Prodigy 90 points

    Hey Evan, 

    So I looked over the sample code and it works the same as the driverlib.  The only difference I found was in the trim functions (example code: Software_Trim/driverlib: privateCSComputeDCOFTrim).  

    In the Software_Trim, there was an additional condition OR'd into the exit loop setup of newDcoTap < 50; when this is added to the driverlib code, it works as expected and the registers come out to the same values.  It seems that adding that condition would allow the library to work for these in-between frequencies as well.

    Here is the example code setup in that Software_Trim function with the extra condition circled. 

     

    And here is the driverlib missing that condition.  

    Let me know your thoughts on this. 

    Thanks, 

    Ryan 

  • 0 in reply to Ryan Schuh
    TI__Genius 10060 points

    Ryan,

    I think your analysis is correct. I currently don't have any additional insight as to why the FR2xx devices need this to exit the clock setup successfully. But I would proceed with it since it is recommended by the FR2xx specific example.

    To confirm: does this solve your issue?

    Regards,

    Evan

  • 0 in reply to Evan Lew
    Prodigy 90 points

    Evan,

    Excellent, glad to hear that we are thinking the same thing.  I will continue testing on additional units over the next week or so to verify this solves the issue and will mark it resolved after I complete the testing if it does in fact clean up this issue on multiple units. 

    On a side note, I think that this should be rolled into the library so that it works as expected even in the in-between frequencies.  Is this something that TI will be looking into for a future release?  

    Thanks, 

    Ryan 

  • 0 in reply to Ryan Schuh
    TI__Genius 10060 points

    Sounds good.

    I will submit a ticket to our software team. However, I don't know the the release timeline would be.

    Regards,

    Evan

  • 0 in reply to Evan Lew
    Prodigy 90 points

    Ok, sounds good.  I just think it would be a good add.  

    Will report back next week with good or bad news.  

    I appreciate the help,

    Ryan 

  • 0 in reply to Evan Lew
    Prodigy 90 points

    Hey Evan, 

    I have tested this change on more boards and found it to work well. 

    My final fix was adding the additional condition to the driver library as this allowed the code to remain mostly the same and then I tested the previously working boards clock speed vs their new clock speeds with the update and saw no change in clock speed.  

    Thank you for you help, I have marked the answers that solved this issue. 

    Ryan

**Attention** This is a public forum