Please enable JavaScript to view this site.

winIDEA Help

Version: 9.21.239

Infineon AURIX: LBIST handling in winIDEA

In this topic:

Introduction

Requirements

Invoking LBIST via boot rom (SSW) via setup a certain bit within UCB BMHD0

Invoking LBIST via user code

Code examples

 

 

Introduction

This topic describes how to execute LBIST via boot rom (SSW), either by setting a certain bit within UCB BMHD0 or via user code.

 

Logical Built-In Self Test (LBIST) is a form of built-in self-test in which the logic inside a chip can be tested on-chip itself without any expensive Automatic Test Equipment. For AURIX TC3xx memory parts (MBIST) are not included.

 

There are two possibilities to execute LBIST, each with different impacts for debugging and tracing:

Invoking LBIST via boot rom (SSW) via setup a certain bit within UCB BMHD0

Invoking LBIST via user code with code examples

 

 

Requirements

winIDEA IDE

BlueBox iC5000, iC5700

 

 

Invoking LBIST via boot rom (SSW) via setup a certain bit within UCB BMHD0

If a bit is set, SSW executes LBIST automatically on power-on only. LBIST is not executed on all other kinds of RESET (e.g. warm PORST, system\application reset).

lbist-ucb-plugin

 

number1

Ensure that Vref is enabled via Hardware / CPU Options / Hardware.

number2

Run the application.

Debug status should be          RUNNING         .

 

number3

Power-cycle the target.

Due to VCC loss, winIDEA will quickly reconnect.

winIDEA Debug status will change from          SoC RESET         to         RUNNING         . If you already have a breakpoint set, it will stop the execution when hit.

 

Number4

Stop the execution.

Debug status will be          STOP         .

 

Number5

Verify whether LBIST was successfully executed via the SFR bit LBISTDONE using the SFR Window.

 

 

LBIST executed

LBIST executed

LBIST not executed

LBIST not executed

 

Warning_orange

The bit that was set will be erased if a reset occurs!

 

i-icon

Because of the Vref loss, the debugger can react very quickly compared to checking MCU state via status read (every 500 ms by default) as in the second example (below), because the debugger doesn't get notification about LBIST as it does via Vref or the normal RESET line.

 

Invoking LBIST via user code

If LBIST is not successfully executed or other reasons are  preventing using the Boot-Rom/BMHD related LBIST execution, user code could invoke it independently. Below is a simple, working example using TASKING Compiler:

 

SCU_LBISTCTRL0.B.LBISTRES    = 1;         
SCU_LBISTCTRL0.B.PATTERNS    = 0x200;     
SCU_LBISTCTRL1.U             = 0x54000007;
SCU_LBISTCTRL2.U             = 0x86;     
SCU_LBISTCTRL0.B.LBISTREQRED = 1;         
SCU_LBISTCTRL0.B.LBISTREQ    = 1;         

 

When LBIST is finished, the debugger gets hit by an internal AURIX System Reset. This special reset is not visible at MCU Reset, meaning there is no signaling via the Reset line. Therefore, the debugger recognizes the lost connection when it periodically (every 500 ms) checks the MCU status. Normally, this check is not performed as often for performance reasons (e.g., Real-Time watches). After losing connection, the debugger needs to re-establish the Debug session, breakpoints, and other settings.

 

Debug status in winIDEA will be          SoC ATTACHING        . Breakpoints are re-established once the Debug connection is valid again. This process takes a significant amount of time while the MCU runs code uncontrolled after the LBIST reset.

 

The timeline shows what happens when LBIST is started from the user code.

lbist-mcu-gap

 

If you need investigate the gap period when MCU runs uncontrolled, you can:

Check Quick LBIST detection option via Hardware / CPU Options / SoC in winIDEA which yields status check more often (but reduces debug performance) OR

Instrument your code using the example provided

 

Code execution stops after debug connection is restored.

 

i-icon

The debug() command becomes active, if/after debug connection is established. If you try without the while() loop, it will get ignored.

 

In the example the iCounter value was between 2.3 and 9.6 million with Quick LBIST detection and between 12 and 14 million without this feature after several measurements. These values are expected to be very different because it is not known on a timeline when the status request failed and winIDEA started re-connection to MCU. Note that you have to get out of this _debug() loop via winIDEA Goto option.

 

The software instrumentation is a solution to stop your application on a certain point in code after LBIST execution was invoked by code and continue with debugging and tracing from there. The_debug() instruction is a universal approach to stop within code.

 

Code examples

volatile unsigned int iCounter, dummy1;
// ask if LBIST was done successfully
dummy1 = SCU_LBISTCTRL0.B.LBISTDONE; //SCU_LBISTCTRL0_LBISTDONE = 1 if LBIST executed

 
// Loop for waiting until Debug connection is re-established, then stop.
//The “iCounter” is for control only.

 
    if (dummy1)  // LBIST recently executed
            {
              while(1)
                  {
                      iCounter++;
                      __debug();
                  }
            }
 

 
// Invoke LBIST via Code if it was not already executed
if (!dummy1)  // no LBIST executed, invoke one via Software
{
/* LBIST execution */
SCU_LBISTCTRL0.B.LBISTRES    = 1;         
//reset LBIST controller-clears results of previous execution and LBISTDONE bit, new LBIST is possible
SCU_LBISTCTRL0.B.PATTERNS    = 0x200;     
//set 80 pattern number,number of scan-patterns-scan captures
SCU_LBISTCTRL1.U             = 0x54000007;
//set seed to 7, 7th pattern is applied to EDT, SPLITSH = 4, four scan partitions. LBISTFREQU=5
SCU_LBISTCTRL2.U             = 0x86;     
//LBIST Maximum Scan-Chain length
SCU_LBISTCTRL0.B.LBISTREQRED = 1;         
//LBIST execution request (safety double of LBISTREQ)
SCU_LBISTCTRL0.B.LBISTREQ    = 1;         
//LBIST execution request (origin)
}

 

Copyright © 2024 TASKING Germany GmbH