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: BIST time

Part Number: TMS570LC4357

Hi Team,

customer use safety lib to do self test and find the execution time has big difference when running PBIST on all rom memories, which make the time of software initialization too long. so customer want to know the reason on this and do some study.

Currently customer find the reason is that for current software version, after calling the PLL self-test function and finish the self-test, the clk doesn't change back to PLL1 and stay in OSC, so it makes the time longer.

But they do not find the root cause that trigger the issue. And they have two questions: 1. they change the initialization code ( IO overturn) in Main function which should have no relationship with this, but it will trigger the issue 2. For this version of software, the action on clk change is not same when do step by step execution or one time execution on check PLL1slip.

Regarding current PLL self-test function, datasheet mentioned you need to disable PLL first if you want to clear slip bits, but clearing slip is put after CLK change back to PLL1 in  self-test function.  Based on this, customer add 38us delay ( delay function in normal time base, in this working condition, it should be ~400us)  after the code" restore the pll multiplier value" and also add 38us delay before the code that change clk source back to original clk, then no issue and the results are expected  at both step-by-step execution or with no simulator. Please kindly check if the issue is caused by the function and if the work-around above is reasonable.

Thanks.

BRs

Given

  • Hello Given,

    After PLL slip happens, the PLL clock switches to the OSC. After PLL selftest (PLL slip), please follow the procedure (TRM, 14.5.4 recovery from a PLL failure) to recover the PLL.

  • Hi QJ,

    Thanks for your reply. But it seems still cannot solve customer's question.

    Customer has read the part you mentioned in your reply before, then they do debug on check PLLSLIP.

    So please kindly check the questions " please kindly check if the issue is caused by the function and if the work-around above is reasonable." . Thanks.

    BRs

    Given

  • Hello Given,


    The workaround looks fine, but it may not work for all the PLL settings. When the PLL slip occurs, please follow the recovery procedure to recover it. Customer should use a while() to check the flag instead of adding a delay function.

    1. Switch all clock domains from PLL1 to the oscillator

    HL_systemREG1->GHVSRC = 0x0U;

    2. Disable PLL1

    HL_systemREG1->CSDISSET = 0x2U;

    3. Wait till PLL1 is disabled

     while((HL_systemREG1->CSDIS & 0x2U) == 0U){

     } /* Wait */

    4. Restore the PLL multiplier value

    HL_systemREG1->PLLCTL1 ^= 0x8000U;

    5. Enable PLL1

    HL_systemREG1->CSDISCLR = 0x2U;

    6. Wait till PLL1 is enabled

    while((HL_systemREG1->CSDIS & 0x2U) != 0U){

     } /* Wait */

    7. Switch back to the initial clock source

    HL_systemREG1->GHVSRC = ghvsrc_backup_value;

    8. Clear PLL slip flag

    HL_systemREG1->GBLSTAT = 0x300U;

    9. Clear ESM flag

    HL_esmREG->SR1[0U] = 0x400U;

    10. Restore the PLLCTL1 register

    HL_systemREG1->PLLCTL1 = pllctl1_backup_value;

  • Hi Qingjun,

    Thanks for your reply. customer feedback it's hard to apply while{}. 

    Customer's main request is to 

    a. Is there something wrong on Check Pllslip funciton? 

    b. why does changing the code in initialization trigger the issue? 

    Thanks. 

    BRs

    Given

  • Hello Given,

    The safety library doesn't have PLL slip selftest. It has ESM application callback function to handle the ESM errors. But there is no ESM callback in case of failures in the selftest.

    If you manually trigger the PLL slip (tell me how did you do it), the clock source is switched to OSC automatically, and the ESM callback function doesn't recover the PLL from the PLL slip. After PLL slip happens, you need to follow the procedure listed in my previous post to recover the PLL.

    Can you tell me which function in the safety diagnostic library is used for your PLL selftest?

  • Hi QJ,

    Thanks for your reply .

    Regarding your questions, customer just call the checkPLL1slip and check PLLslip2 function. These are in the safelib library, demo_app - common-source file - faultinject.c.

    Thanks.

    BRs

    Given

  • Hello Given,

    Thanks. I just checked the PLL slip function, Everything looks fine except for this instruction:

    I think the while() loop should not be commented out.

    This function restores the PLL after the PLL slip (expected).

  • Hi QJ,

    Thanks for your reply.

    But customer feedback in released version they received, this sentence is not comment out actually. Please kindly check. Thanks.

    BRs

    Given

  • Hi Given,

    I just tested the PLL1 slip function, it works as expected. I monitored the ECLK which outputs the VCLK/10 (7.5MHz). When the PLL slip happens, the ECLK outputs 400KHz waveform which is from 16Mhz OSC. After PLL selftest, the ECLK comes back to 7.5MHz.

    BTW, please do not execute the selftest code step by step.