Restore MPC5777M chip to default

[paulodasilvapin]

Hello all,

We have already managed to start and configure all cores and run product applications with MPC5777M.

We have also succeeded to configure XBIST tests with DCF records.

Unsing MPC5777M demoboard, the problem is that we have made tests before finding correct configuration on some chipsets and in some of them now it is not possible to configure PLL and running mode anymore in MC_ME : then it seems not possible to activate core0/1 anymore 

I know DCF records are OTP. But just in case, is there any way to restaure default values or at least boot on the chipset even with bad DCF records ? Is there any solution to configure PLL and activate the desired cores ?

Thank you

Best regards.

[paulodasilvapin]

Hello,

ok for part 1 : I've had no hope you say anything else.

for part2 : we use a code to configure PLL/MC_ME (using your good examples) that works fine for every chipset we have except 2 where we are sure that DCF records for XBIST tests are not set correctly. For these 2 chipsets, we don not find a solution to finish the setting of PLL/MC_ME because T32 fails with "debug port fail" whn trying to write the second key that activates the DRUN mode. With others chipsets this never happens of course. We do no see any link between bad DCF configuration and key activation. 

Best regards

Paulo

[petervlna]

Hello,

We do no see any link between bad DCF configuration and key activation.

That's hard to comment. Yes, there should not be directly, but try to do mode transition to mode with IRC (not PLL). I am quite sure it will work. In BIST DCFs you also configure PLL so it is possible.

But if you reconfigure it again then the DCF configuration is overwritten.

I would test failing chip in NXP evaluation board first as there could be some HW issue.

The question is was the sample working (mode transition to mode with PLL) before you program DCFs or not?

"debug port fail" whn trying to write the second key that activates the DRUN mode

Hmm, how about reset line? Sudden loss of debug looks like voltage issue to me. Have a look at HDD_HV and VDD_LV and also reset line while this event occur to see if there is not any other problem.

Best regards,

Peter

[petervlna]

Hello,

I know DCF records are OTP. But just in case, is there any way to restaure default values or at least boot on the chipset even with bad DCF records ?

No, there is not. Therefore it is called OTP.

Is there any solution to configure PLL and activate the desired cores ?

Sure, there could be. But since you do not shared anything regarding what you did with micro I can only tell you to set Clocks for PLL and do mode transition in application.

Best regards,

Peter

[paulodasilvapin]

Hello Peter, "I would test failing chip in NXP evaluation board first as there could be some HW issue." => as a matter of fact we are using NXP evaluation board. We used this board to find good DCF record configuration before use it in real product. And "corrupted" chipsets are those used to do the testing. "The question is was the sample working (mode transition to mode with PLL) before you program DCFs or not?" => Yes it was. I add a dump around DCF record area between in the interval [0x00400200 ; 0x004007FF]. I think we are not able to add a new DCF record to restore to some other values. Best regards

[petervlna]

Hello,

I had a quick look at your DCF. I see no issue in it. What is in content of SSCM_STATUS [CER] ?

But anyway, if you did tests with DCF records on them, I would not use them in production anyway.

Once you find the desired DCF configuration, try do not overwrite any DCF record by new one as this will prolong the time spend in reset. As SSCM must read all records until it finds DCF end record.

I do not know what can be wrong with your configuration. Maybe try to erase the chip, where there is no SW and load an example code to test PLL switch.

https://community.nxp.com/docs/DOC-329858

Best regards,

Peter

[paulodasilvapin]

Hello Peter,

No my intention is not to use the tested chipsets in production. I would only find a way to make them work again like before to use them again for other testing purpose.

To answer your questions:

SSCM_STATUS[CER] = 0x01 with your software or with my software (both uploaded in internal FLASH).

And with your software, there is no problem in configuring the PLL and changing the mode.

Therefore, I'll need to have a close look on your code towards our code to look for differences. One obvious is that we use PLL1 as system clock and clock dividers configuration is different. But I don't think that is the reason it does not work. 

Best regards

Paulo