• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 78 subscribers
  • Views 483 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.

MSP430FR6047: ERROR: The output frequency of the HSPLL is invalid

Lasse Lundholm
Intellectual 280 points
Part Number: MSP430FR6047
Other Parts Discussed in Thread: CC1310, , ENERGYTRACE, MSP-FET

What USS parameters help determine the HSPLL output frequency? Or which factors affect it.

I cannot share my code with you here - sorry for that. But maybe you can give some general advice about how to manage the HSPLL output frequency.

I have developed a, rather extensive, program on a CC1310 that communicates with the MSP via I2C including using the I2C_IRQ line.

When the parameters have been adjusted, the CC1310 receives the measurements from the MSP, basically mimicking what the USS Design Center GUI does - just automatically. So far so good. The first version of the program just poll's on the IRQ line with GPIO_read.

Next step, the one causing the issue, is implementing the POSIX semaphore instead of the GPIO_read, using sem_wait and sem_post. The actual setup of the semaphore seems to work as intended. A sem_wait halts the CC1310 program and wait for an interrupt on I2C_IRQ and a sem_post continues the program and it receives the I2C package(s) from the MSP. In the beginning I was able to run the program but it ran into some timing issues so the expected packages didn't match up.

But now the problem with the HSPLL has come along.

The problem is that when I try to set the parameters on the MSP now, it returns error 22 - The output frequency of the HSPLL is invalid. This is the exact same code that runs perfectly well with GPIO_read.

Im using:

CC1310, Code Composer Studio 9.3.0, SDK 3_20_00_23

Kind regards

Lasse

  • 0
    TI__Genius 12615 points

    Hi Lasse,

    We have seen issues with the HSPLL frequency on some boards which may be related to the hardware. The amount of time the FR6047 is on seems to increase the frequency of this error if there is a problem with the board.  Do you have another board you can test with?

    BR,
    Leo

  • 0 in reply to Leonardo Estevez
    Intellectual 280 points

    Hi Leo

    Yes I have tried another board. The issue with the HSPLL seemed to be gone when running the code for the first time (the old error I had came back). But then a second run saw the HSPLL error return.

    Going back to the GPIO_read version of the code is no problem. Runs without the errors. So it seems to be more software related, more specifically related to my implementation of the semaphore. But this leaves me somewhat clueless to the cause of the error.

    The semaphore works by using an interrupt, that is setup using the GPIO interrupt example from the Project Explorer.

    kind regards

    Lasse

  • 0 in reply to Lasse Lundholm
    TI__Genius 12615 points

    Hi Lasse,

    Can you check to see how long the MSP430FR6047 is in active mode in the two versions of your code?

    BR,
    Leo

  • 0 in reply to Leonardo Estevez
    Intellectual 280 points

    Im not sure how to measure that exactly?

    kind regards

    Lasse

  • 0 in reply to Leonardo Estevez
    Intellectual 280 points

    EDIT.

    I seem to somehow has solved the HSPLL error, at least for now. I commented a GPIO_disableInt and GPIO_enableInt functions out on the CC1310. Again I have no idea how that affects the HSPLL clock on the MSP?!!

    I would like to try and understand it better, so it's too early to click "resolved" I think.

    kind regards

    Lasse

  • 0 in reply to Lasse Lundholm
    TI__Genius 12615 points

    Hi Lasse,

    One of the main issues we've seen has been with the tolerance of the resonator used on the EVM.  There is a tolerance defined which can be increased for resonators that aren't operating within the expected tolerance: 

    USS_HSPLL_TOLERANCE

    BR,

    Leo 

  • 0 in reply to Leonardo Estevez
    Intellectual 280 points

    Thank you very much

    As of now the issue is gone, even though the exact cause and solution is unknown. If it returns I will try and change the tolerance and see if it solves the problem.

    I'm not sure if I should cllick "solved" for this one just yet? But I appreciate the response and suggestions.

    kind regards

    Lasse

  • 0 in reply to Leonardo Estevez
    Intellectual 280 points

    The error returned for some reason at a point in the development, the conditions causing the error is still unknown to me.

    I tried to increase the tolerance of the HSPLL which didn't help.

    Status though, is that I reverted back to the stage that worked without the error, and worked at some timing issues with the communication between the CC1310 and the FR6047. The code actually runs but it would be unfair to say robustly :-)

    Thank you for the help so far.

  • 0 in reply to Lasse Lundholm
    TI__Genius 12615 points

    Hi Lasse,

    I'm wondering if the change in your code is keeping the FR6047 from going to sleep.  Is there any change in sleep behavior for the version of your code that works?

    BR,
    Leo

  • 0 in reply to Leonardo Estevez
    Intellectual 280 points

    Hi Leo. Sorry for the delay in my reply. The problem has more or less disappeared. It comes back on rare occasions but i usually solved by dis- and reconnecting the debugger. I managed to figure out how to use the EnergyTrace in the MSP-FET to see which states the MCU is in. During measurements it looks something like this:

    With the MSP spending approximatly 95% of the time in LPM and 5% in active. Think this works as designed.

    Thank you for your help so far. Appreciate the support.

    Lasse

  • 0 in reply to Lasse Lundholm
    TI__Genius 12615 points

    Hi Lasse,

    I'm glad to see you're making good progress.  I'm going to close this thread for now, but will be happy to support a new one if you run into more issues.

    BR,
    Leo

**Attention** This is a public forum