TMS570 LBIST trouble

Debug is one of the events that exit you from the WFI.  So you can't 'step' through WFI and stop on it, you'll go right through.

Recommendation is to put the WFI in a background/idle loop.

Would this explain what you are seeing?

It gets stuck regardless of whether I do a free run, step through, or run without the debugger.

Further, I know that when it was working before, I could step through with the debugger, even though it is not supposed to work that way.

John,

The debugger is odd.  I added an 'asm(" WFI");' statement to a skeleton halcogen project in main() and confirmed the expected debug behavior;  maybe there is a difference in how we are running the experiment.

Do you have a copy of the  "ARM ®  Architecture Reference Manual ARM ® v7-A and ARM ® v7-R edition"?   The WFI wakeup events are listed in it.

Aside from debug,  FIQ, IRQ, and an Async Abort are other sources.  The manual says these are not (from a wakeup standpoint) masked by the CPSR bits that mask the interrupt/abort execption.  So even if IRQ is disabled in CPSR,  an IRQ asserted on the processor boundary would be enough to exit the WFI.   This would be why you would want to put the WFI in the loop.

The LBIST self-test should exit with a CPU reset, so this particular WFI won't be something you'll exit and continue running from anyway. 

Hmm, I tried putting the instruction in a loop and it still just hangs on it in the loop.

volatile U32 delay;

{
    /* STC clock is now normal mode CPU clock frequency / 2 */
    Sys_2_Registers.Stc_Clock_Prescaler = (STC_CLOCK_DIVIDER(FMZPLL_LBIST_R_DIVIDER));
    Lbist_Registers.Stc_Clock_Prescaler = (STC_CLOCK_DIVIDER(FMZPLL_LBIST_R_DIVIDER));

    /*
        2. Clear CPU RST status bit in System Exception Status Register in the system Module. SYSESR[5] = 1
    */
    Sys_Registers.Exception_Status = STC_LBIST_RESET_STATUS;

    /* Run specified no of test intervals starting from interval 0 */
    /* Start test from interval 0 or continue the test. */
    if(restart_test != FALSE)
    {
        Lbist_Registers.Global_Control_0 = LBIST_RESTART;
    }
    else
    {
        /* Do not set the LBIST restart bit */
    }
    
    Lbist_Registers.Global_Control_0 |= (no_of_intervals << LBIST_INTERVAL_COUNT_SHIFT);

    /* Configure Maximum time-out period */
    Lbist_Registers.Stc_Run_Timeout_Preload = max_timeout;

    /* Enable self-test */
    Lbist_Registers.Global_Control_1 = STC_ENABLE;

    /* wait for 16 VBUS clock cycles at least, based on HCLK to VCLK ratio */
    for(delay = 0;delay<32;delay++)
    {
    }

    for(;;)
    {
        asm(" WFI");
    }
    /* Idle the CPU so that the self-test can start */
// JED TEMP DISABLE   WaitForInterrupt();

}

Do you have anything set up such that if the CPU did run the self-test and it reset the CPU afterwards, you'd know it.  Or would it just fall through and hit the same WFI loop?

If so, and you're not seeing the Self Test start, then probably there's an active interrupt requst making it to the CPU.  What do you see in the VIM INTREQ and REQENASET registers?

(0xFFFFFE20 - 0xFFFFFE48)?

-Anthony

The reset reason is determined from SYSESR at startup. If the CPU resets from the LBIST then it knows LBIST is completed and checks the fail status and continues.  It wouldn't go to the same WFI loop.

VIM INTREQ are all 0x00000000

VIM REQENASET0 is 0x00000003 the rest are 0x00000000

John,

Looks like we're ruling out many of the obvious things.  Would it be possible for you to send your project?  That might help speed the analysis.

Well, it seems like the direction we are going to take on this is to go back to the original startup code that had working LBIST and then add in the changes from the "new" startup.

Too bad we couldn't figure this out.  I have been scratching my head on it for a week or so now because this is not an obvious problem.

I will fill you in if one of the changes I make to my working version somehow breaks the LBIST.

If you want to keep looking into this, then I will leave a summary of the startup code up to LBIST, but I can't send my project.

Step 1: Enable Vector Floating Point Unit

Step 2: Initialize Registers

Step 3: Check for reset type (SYSESR).  If power on reset, Clear/Initialize RAM.

Step 4: Setup Stack pointer

Step 5: Initialize CPU clock registers

Step 6: Set PLL frequency for startup

Step 7: LBIST

John,

If you can send your .out file along with information about the address of the WFI loop - that may be enough to do some additional debug.
If you don't want to post it on this forum, you could email to me or we can setup another more secure mechanism to do the exchange.

You can send me a direct email if you're interested in pursuing this route.

John,

It could be interesting to know what is in the SYSESR register. 

Also, your order of init is OK, however, a BR to 0 would kill it.  I am working with one of your coworkers and we ended up splitting up the register init such that your first two lines become:

1) init CPU registers

2)enable FPU

3)init FPU registers

He was getting an unexpected abort with the original method.

John,

Wanted to check if you've resolved this problem - or if there's a next step.

The problem has not been resolved.  Even using the known working code, it was not working.

I tried a number of different things over the last week, but have had no success.

John,

Is it possible for you to send us the code then?

If you can send it but can't post it publically - my email is 'a dash seely at ti dot com'