• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 190 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.

TMS570LC4357-EP: Found an issue with ERRATA Hercules PLL Advisory SSWF021 #45 Workaround

Donald Lam
Prodigy 30 points

Part Number: TMS570LC4357-EP

Hello, We have been working with the TMS570LC4357-EP chipset.
To minimze impact of setting PLL, we applied advisory spna233b (SSWF021 #45) as linked here:
Hercules PLL Advisory SSWF021#45 Workaround (Rev. B) 

We found that there is an error in the errata:
In function _errata_SSWF021_45_both_plls , the line: 

failCode = disable_plls(SYS_CLKSRC_PLL1 | SYS_CLKSRC_PLL2)

Will overwrite the failCode set by the for loop. We have tried setting:

failCode |= disable_plls(SYS_CLKSRC_PLL1 | SYS_CLKSRC_PLL2)

to conserve the failCode, but this results in a failCode = 3 and appears to force PORST  to 1

  • 0 in reply to Donald Lam
    Prodigy 30 points


    Image for reference

  • 0 in reply to Donald Lam
    TI__Guru* 79226 points

    Hi Donald,

    Donald Lam said:
    to conserve the failCode, but this results in a failCode = 3 and appears to force PORST  to 1

    Apologies for the delayed response!

    Are you sure you are getting this failCode =3 for your normal execution, usually this should not happen after that retries.

    I want to get clarifications for below things.

    1. Are you still doing "_errata_SSWF021_45_both_plls" in power ON reset only, because this workaround is required in power reset only.

    2. I modified code as you but i didn't face any issues, as shown in below picture i am getting failCode as 0 only.

    Let me explain procedure that i followed.

    i) First i modified code as you suggested:

    ii) And then i added this while loop to act as a breakpoint, because i don't want to do it in debug mode because in debug mode we can't enter into this POWERON_RESET case.

    iii) After doing these modifications i directly build and loaded code into flash.

    iv) Now i did power ON reset once (removed and re-plug the power).

    v) Now to connect the board without altering existing flow i did some other steps like as follow

    vi) First i removed the gel file in launch configurations like as below:

    vii) After this i launched this modified target configuration

    viii) After launching target configuration, i connected to core

    ix) Now i loaded symbols:

    x) After loading symbols you can see our code exactly pause at the while loop we created:

    xi) Now change this loop variable value to 0 to exit from the loop and now we can set the break point at our newly added code

    xi) Now you can see the failCode value is just 0 not 3,

    It is same just before terminating function also

    Note:
    I tested this on RM57x because i am lack of LC4357 now with me, but this procedure should be same and applicable to LC4357 as well.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 30 points

    Hello Jagadish,

    Here are the answers to your question:
    Yes, we only call this function following a power ON reset event. i.e. only if the power on reset bit is set. To be specific, we checked via a condition

    (0xFFFFFFE4 & (1U <<15U)) == (1U <<15U)

    that the power on reset bit is set before calling the errata.


    After more investigation of the source code we Isolated the issue: there were coding standard changes done to the errata_SSWF021_45_both_plls function and we replaced these lines:

    /** DCC1 Clock0 Counter Seed value configuration */
dccREG1->CNT0SEED = 138U;
/** DCC1 Clock0 Valid Counter Seed value configuration */
dccREG1->VALID0SEED = 10U;
/** DCC1 Clock1 Counter Seed value configuration */
dccREG1->CNT1SEED = 489U;


    With this:
    /** DCC1 Clock0 Counter Seed value configuration */
dccREG1->CNT0SEED = 0x00000138U;
/** DCC1 Clock0 Valid Counter Seed value configuration */
dccREG1->VALID0SEED = 0x00000010U;
/** DCC1 Clock1 Counter Seed value configuration */
dccREG1->CNT1SEED = 0x00000489U;


    We are still not sure why this would have affected compilation but after reverting to the old code the issue disappeared.
    The comment about this line still stands and I recommend correcting the advisory in case this affects other developers.

    Donald Lam said:
    failCode |= disable_plls(SYS_CLKSRC_PLL1 | SYS_CLKSRC_PLL2)


    Additionally the forcing of PORST  to 1 appears to be a consequence of proprietary code on our implementation of the PLL Lock Failure handler, after the errata is called. It causes the system to reset when the failure code of the errata is not 0.

  • 0 in reply to Donald Lam
    Prodigy 30 points

    After discussing more, the error in the seed value was misrepresentation of the value, due to the 0x added, which changed the value to a hex representation.

    Instead of using 138, 10 and 489 (decimal) as suggested the code was using 0x138, 0x10 and 0x489 (hex) = 312, 16 and 1161.

    The errata is correct aside from the failCode |= disable_plls(SYS_CLKSRC_PLL1 | SYS_CLKSRC_PLL2) line

  • 0 in reply to Donald Lam
    TI__Guru* 79226 points

    Hi Donald,

    Donald Lam said:
    Instead of using 138, 10 and 489 (decimal) as suggested the code was using 0x138, 0x10 and 0x489 (hex) = 312, 16 and 1161.

    Yes, your understanding is correct.

    Those are decimal values, changing them to hex make the values very high and eventually this leads to oscillator clock verification fail w.r.t reference clock.

    Donald Lam said:
    The errata is correct aside from the failCode |= disable_plls(SYS_CLKSRC_PLL1 | SYS_CLKSRC_PLL2) line

    Thanks for pointing out this issue, we will note down this and will take corrective action accordingly.

    --
    Thanks & regards,
    Jagadish.