Unreliable Vybrid boot (HW issue)

[kubiznak_petr]

We experience a serious issue with few pieces of the MVF61NS151CMK50/2N02G microprocessor. Currently I have one of them on my table, soldered on a board. The problem is that it boots highly unreliably. I guess the origin is in the BootROM, as u-boot does not even start to boot (no console output; though the problem is not in the console).

On power-cycle, the MPU sometimes boots, and sometimes it does not. It might be 50/50. It behaves the same when booting from MMC and NAND (set by GPIOs). On boot failure, it does not enter the Serial Boot Mode (at least no USB device connects to the PC).

We discovered one very "interesting", but also crucial thing. Triggering the RESETB pin (T4) does not change anything! I.e. if the MPU starts booting after power-on, triggering the reset does reset the MPU and it boots successfully again (and again and again). If it does not boot after power-on, triggering the reset does not reset the MPU, it never starts booting. Hence it is not even possible to workaround this issue with watchdog!

We watched the voltage levels and signals development (XTAL, RESETB), but did not find any significant difference between the working and broken state. We welcome any advice on what to measure to solve the issue. Anyway, the RESETB observation seems to point on a silicon issue, doesn't it?

Is this a known issue? Is there a way to fix, or do we need to replace the MPU?

[kubiznak_petr]

Hi Alfred1z​, sorry I was out of office. I AM willing to fill the form, but I will not publish it on the community, as it contains confidential information. Both of the threads you sent me as examples are private, I'm not authorized to access them. This thread is public. Please provide more confidential way to send the form. Also please explain the abreviations used in the form. Thank you.

[alfred_liu]

Hi, kubiznak.petr​

if you don't want to send me those information.

please tell me the customer name at least, thanks.

next time, we need to get the filled file before any comments.

[alfred_liu]

Hi, kubiznak.petr​

you may misunderstand my meaning. :smileyhappy:

this file is required when we support in the community for tracking and will be reported to my manager every week.

it became a madatory requirement from my manager of manager of manager......

sorry to make you confusion.

you can fill the file and enclose here.

you can find many many reference in the community.

[BYD/MX6UL/T-BOX]Schematic review ---Pls help to assign it to Weisong Liu

philips: i.MX6SX,doctor monitor, ask schematic review.

and so on......

any futher question, you also can ask administrator here; karinavalencia.

[alfred_liu]

Hi, kubiznak.petr​

could you help on the enclosed file.

it's the requirement from our management team.

many thanks

[kubiznak_petr]

Hi Alfred1z​, what do you mean by that it is a "requirement"? Sounds a little bit like threatening...

I was going to fill the file right after you sent it. Anyway I found two pitfalls in it. First I don't understand the Customer Phase abbreviations. And second I did not find how to officially submit the form. I will not publish this kind of information on the community. Please provide an official (i.e. trustworthy and confidential) place for submission, and explain the abbreviations. Thank you.

[alfred_liu]

Hi, kubiznak.petr​

sorry to forgot the attachment.

please help to fill it.

many thanks.

[kubiznak_petr]

I believe I solved the problem. Sorry for blaming that it might be a silicon issue, it is not. The problem was in the PTB2/RCON31 pin, which was not handled. That resulted in unpredictably changing value of BOOT_CFG4[7], described in RM as Infinite Loop (Debug USE only).

What is still an issue for me is why does this value persist across external resets? And what does actually this Infinite Loop do? I did not find anything about it in the RM (Rev. 8).

[alfred_liu · Accepted solution]

Hi, kubiznak.petr​; karinavalencia​

for your question 1:

the boot configuration pins are latched during POR_B (power-up reset ,which is internal in Vybvrid), not the "RESET_B", so when the pin is latched with a wrong value , you cannot revover by this "reset", but power up again.

for your question 2:

the Infinite loop mode is for NXP chip debug use only, which provide a enterance for the debug tool, when chip goes into this mode, it will wait for some commands from debug tool, you cannot do anything at that time.

hope this answer you.

additional request for you:

please help to fill the enclosed file, we need it for customer support tracking, thanks.

[kubiznak_petr]

Thanks for your reply, Alfred1z, it answers my question.

Regarding the "enclosed" file, I can't see any...