MPC5777C, STCU2 LBIST #5 problem

[krywes]

Hello all.

I have an issue with STCU2 on the MPC5777C. It has been setup for on-line tests according to AN5288 (Rev 1, 09/2018) and it works just fine when running on a SPC5777CLMM03.

However, when we used another batch of hardware units fitted with the SPC5777CCMM03 the BIST fails on LBIST #5. All other LBISTs and MBISTs passes. The differences between these two CPUs according to the data sheet is the type of voltage regulator used, but also the "security firmware" version (2.08 for the L-version and 2.07 for the C-version). I assume that "security firmware" refers to the CSE module, which is one of the modules included in the LBIST #5 group.

The expected MISR for LBIST #5 according to the AN5288 setup is 0x6A3C6D9C (low) and 0x3AB9877C (high). For the C-version however, we end up with MISR 0x11B4A4BC (low) and 0x61184287 (high) instead. This has been verified on multiple CPUs.

So, my questions are:
- Should the STCU2 be configured differently depending on the firmware version of the CSE. I have not been able to find any information indicating this, or
- Is my problem based on the difference in voltage regulator, badly setup oscillators/PLL's or something similar?

Clocks are setup as follows:
XOSC = 40 MHz
PLLDIG.PLL0DV.R = 0x2006200Fu;
SIU.SYSDIV.R = 0x0100B010u;

Best regards
/Jimmy Westerlund

[krywes]

Hi Peter.. 

Thanks for your fast reply and sorry for my late follow up.

Further investigation on these cards showed that the CPU claimed to be in "MCU production" life cycle state, and that the entire UTEST area was erased (all ones). As the flash array is part of LBIST #5, could that be the reason why the self tests failed?

After checking various voltage levels etc on the card (in case the powering on sequence was bad) we tried to manufacture one card with a CPU from another batch and this CPU appears to work just fine, LBIST #5 passes and UTEST is accessible as expected. Is it possible that there is a batch of CPUs out there which have been delivered without being properly tested and configured at NXP factory (i.e. UTEST setup and life cycle set to OEM Production)?

Best regards
/Jimmy Westerlund

[petervlna]

Hello,

he entire UTEST area was erased (all ones).

Hmm, if you erase the UTEST you will setup unknown password to PASS module and JTAG. So once you migrate to later lice cycle you will lock the device with unknown passwords.

As the flash array is part of LBIST #5, could that be the reason why the self tests failed?

How can be memory array part of logic test which test registers integrity? This just does not make sense.

Is it possible that there is a batch of CPUs out there which have been delivered without being properly tested and configured at NXP factory

I barely doubt this as we guarantee 0ppm for 10M or so.

Is the board NXP Evaluation board or your own board?

What is the content of ERR register of STCU after BIST?

Best regards,

Peter

[krywes]

The boards is of our own design. The current design is our fourth iteration of hardware design (I think) so the design has been tested before, but that was mainly with the L-version of the CPU. The PCB however is prepared for both the C and the L-version. Due to availability issues the latest batch was manufactured using the C-version instead of the preferred L-version of the CPU.

All CPU-cards (about 10 pieces) in that batch failed on STCU self-test on LBIST #5. That was when we started investigating why, which triggered my initial question.

All CPUs used in this batch of cards had the same marking (CTZA1923A LWZACTA).

After your first response we performed some additional investigations, and that's when we found that the UTEST area *appears* to be erased on all these CPU's. We do not know if that's because they have not been tested and programmed at NXP factory, if they have otherwise been damaged or if the cause is something else. However, the remaining flash areas appear to work as expected (can be both programmed and erased).

After this we manufactured one (=1) new CPU card with a CPU from another batch (CTVX2107A QGVXCTA) which had no problem passing the STCU self tests. That's why we where suspecting that it could be caused by a bad batch of CPUs.

We are not currently using UTEST for setting up DCF, setting passwords, storing OTP-data or similar, so no attempts to write to this flash has been performed.

The ERR_STAT register of the STCU2 is set to 0x00000108 (recoverable error and off-line watchdog timeout). However, we are currently not using off-line self tests, only on-line self tests for the moment (initiated when SIU.RSR indicates a power-on reset).

We will discard all these cards and manufacture new ones, so for the moment I'm just asking for my own curiosity, trying to understand why these CPU did not work as expected. We have not performed any additional testings of these CPU's so it might be that, in case they have actually been damaged somehow, there are other parts of the CPU not working as expected and that could be the cause of the failed LBIST #5.

Best regards
/Jimmy Westerlund

[petervlna]

Hello,

Hmm, so you are not running Offline test but offline watchdog expired? Sound strange to me as offline watchdog is started with offline test.

Do you have NXP EVB to test the micro?

So you see the LBSSW5 set after the test?

Do the test pass if you exclude LBIST5?

Do the offline test pass? Because from the ERR register it looks like you are running offline test.

You can try to run my example SW.

Best regards,

Peter

[petervlna · Accepted solution]

Hello,

- Should the STCU2 be configured differently depending on the firmware version of the CSE. I have not been able to find any information indicating this, or
- Is my problem based on the difference in voltage regulator, badly setup oscillators/PLL's or something similar?

LBIST is independent of any FW. As it is testing registers with pattern, and before test it put registers to defined states.

So, no CSE FW nor HSM FW is anyhow involved in BISTs.

Have a look at ERR_STAT register in STCU to see the reason for BIST fail.

Best regards,

Peter