winIDEA Help

Version: 9.21.243

Zoom Window Out
Larger Text | Smaller Text
Hide Page Header
Show Expanding Text
Print Topic
Share This Topic
Save Permalink URL

Navigation: Architecture-specific notes > Infineon TriCore > Debug > How-to guides

Scroll Prev Top Next More

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).

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 not executed

Warning_orange

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

	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.

	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)
}