Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

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

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

  • 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

  • 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

  • Hi Lasse,

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

    BR,
    Leo

  • Im not sure how to measure that exactly?

    kind regards

    Lasse

  • 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

  • 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 

  • 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

  • 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.

  • 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

  • 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

  • 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