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.

RM46L852: PLL fails to start; Errata SYS#046 and SSWF021#45

Part Number: RM46L852
Other Parts Discussed in Thread: HALCOGEN,

Looking for input on two Errata's:

SYS#046: Clock Source Switching Not Qualified With Clock Source Enable And Clock Source Valid

The HalCoGen generated code has the workaround implemented in system.c mapClocks():

/* Work Around for Errata SYS#46:
*
* Errata Description:
* Clock Source Switching Not Qualified with Clock Source Enable And Clock Source Valid
* Workaround:
* Always check the CSDIS register to make sure the clock source is turned on and check
* the CSVSTAT register to make sure the clock source is valid. Then write to GHVSRC to switch the clock.
*/
/** - Wait for until clocks are locked */
SYS_CSVSTAT = systemREG1->CSVSTAT;
SYS_CSDIS = systemREG1->CSDIS;
while ((SYS_CSVSTAT & ((SYS_CSDIS ^ 0xFFU) & 0xFFU)) != ((SYS_CSDIS ^ 0xFFU) & 0xFFU))
{
SYS_CSVSTAT = systemREG1->CSVSTAT;
SYS_CSDIS = systemREG1->CSDIS;
} /* Wait */

Ran across one unit that was hung in the above loop. The PLL1 was not ever valid, i.e. PLL failed to start? This was NOT happening on every power on, but was repeatable.

Then found the other Errata: SSWF021#45 - PLL Fails to Start

This Errata provided code examples for the workaround that starts the PLL at a slower rate, then proceeds forward to configure the PLL as defined in HalCoGen (i.e. 220 MHz).

SPNA233A May 2016 revised Jun 2016 has this code placed in sys_startup.c _c_int00() after checking for a power on reset:

/* check for power-on reset condition */
/*SAFETYMCUSW 139 S MR:13.7 <APPROVED> "Hardware status bit read check" */
if ((SYS_EXCEPTION & POWERON_RESET) != 0U)
{
/* USER CODE BEGIN (12) */
    if(_errata_SSWF021_45_both_plls(5) != 0)
    {
        routine_to_put_into_safe_fail_state();
    }
/* USER CODE END */

Questions:

1) Anyone else experienced an issue with the PLL failing to start? If so, were you able to determine the issue and was it failing on the Errata SYS#046 workaround?

2) Any explanation (hopefully from a TI rep) why the PLL is failing to start? If it is a problem with the RM46x, why is this Errata workaround NOT generated by HalCoGen code like SYS#046?

3) TI recommendation for implementing workaround for SSWF021#45, the SPNA233A identifies timing for various reties up to 5 retries. Can more retries be used or is it recommended to try no more than 5 times?

I have not tried implementing this workaround yet, for the unit that had this issue is no longer showing the issue, we are still trying to reproduce again.

Thanks for any experiences or recommendations.

Don ...

  • Hi Don,

    Sorry for the delay in responding. See my comments below:

    1) Anyone else experienced an issue with the PLL failing to start? If so, were you able to determine the issue and was it failing on the Errata SYS#046 workaround?

    >> The workaround for SYS#46 issue was put in place in case an application attempts to switch over the clock domains to the PLL output clock without first starting the PLL. This workaround is now made ineffective due to the PLL start-up issue. This workaround is now being updated to account for the PLL start-up issue, and will be included in the next update for HALCoGen.

    2) Any explanation (hopefully from a TI rep) why the PLL is failing to start? If it is a problem with the RM46x, why is this Errata workaround NOT generated by HalCoGen code like SYS#046?

    >> This is an issue with all RM4x MCUs and is only likely to happen on power-up, as described in the errata document. The next HALCoGen update will include the recommended workaround for this issue. The workaround for SYS#46 will also use this PLL start-up issue workaround.

    3) TI recommendation for implementing workaround for SSWF021#45, the SPNA233A identifies timing for various reties up to 5 retries. Can more retries be used or is it recommended to try no more than 5 times?

    >> The application can choose the number of times it wants to try starting the PLL. This is application dependent, as some applications have a hard constraint for the time within which the application must be up and running at the target frequency.

    Regards,
    Sunil
  • Sunil,

    Thank you for the detailed information.

    Don ...
  • Sunil,

    Sorry, I have one last question. Now that we have integrated this errata fix into our code base, is there any way to test this implementation? In other words, are there any known ways to get an RM46 to power on with the PLL failure?

    Also, you mentioned that this errata implementation has made the SYS#046 workaround "ineffective". Is there any issues with running both the SSWF021#45 errata workaround a power on reset as well as the SYS#046 workaround that is generated in the HalCoGen code?

    Thanks,
    Don ...
  • Hi Don,

    There is no way to intentionally cause a PLL start-up issue.

    Regarding the workaround for SYS#46, I meant that this workaround is not useful unless it also uses the workaround for the PLL start-up issue. If the application configures the PLL control registers, enables the PLL(s), and uses the recommended workaround to get the PLL(s) to acquire lock before using the PLL output clock for any domain, then the SYS#46 workaround is not required at all. This is the normal sequence of using any available clock source.

    The SYS#46 issue only applies if an application tries to switch over a clock domain to a source (e.g. PLL) that is not enabled or valid yet.

    Regards,
    Sunil
  • Sunil,

    Thanks!
    Don ...
  • Hi Sunil,

    Thank you again for all information you have provided pertaining to the RM46x Errata SSWF021#45.

    Sorry to keep asking more questions, but I was hoping you would know or know of someone at TI that may speak to the following question. We are trying to assess the risk/probability of having this issue, even after implementing the described workaround.

    Again, we are using the RM46L852 microcontroller, and based on the SPNA233A -May 2016 - Revised Jun 2018, Hercules PLL Advisory SSWF021#45 Workaround it states the following:

    Texas Instruments has found that on rare occasions some Hercules Safety Microcontrollers have an issue
    with PLL startup. While Texas Instruments does test for and screen these devices, at the time of
    publication of this report, our screens are not 100% effective. Parts that are affected have advisory
    SSWF021#45 listed in the errata document for that device, if the errata document was published in May of
    2016 or later. The software workaround described in this report, while not 100% effective, significantly
    helps to reduce the occurrence of failures.

    Does TI have any information that may speak to the probability (or numbers) of occurrence of this issue after parts have implemented the described workaround; yet still seeing failure to start the PLL correctly?

    Thanks again,

    Don ...

  • Hi Don,

    As mentioned in the errata description there is a stringent screen in place for this issue, and though it is not 100% effective it has not led to parts being returned back to TI after escaping the screen and then the PLL failing to lock in a customer application.

    Regards,
    Sunil