MPC56xx censorship best practice guide?

[AndreiC]

I was wondering if there is a documented best practice for censoring an MPC5634M or similar?

I know there is a document on how to prevent device lockout via censorship, but wouldn't be more of a collateral piece to the document on how to do it properly?

Thanks,

Andrei

[AndreiC]

Got it.

The key points are that the censorship information is stored in the shadow flash. The shadow flash is a part of flash block 0. You cannot be executing code from flash while erasing the shadow flash because the flash doesn't support read while write, it will cause a machine check and leave you with a bricked processor.

You have to execute the censor and restore code while executing from RAM, not flash. But that also means that you have to be using the 2.1 release of S32DS to get a linker that handles sections properly when setting up a code section in ram.

I've attached a zip file of my project that shows how this is all done; running from flash, ram copied flash code, censoring and clearing censorship, and bypassing censorship on a processor that is already censored.

Plus if you look at the debugger configuration, in the debugger tab, there is the server parameters: -uncensorpassword=c0ffee42cafebeef so that you can use your debugger on your locked processor.

Hopefully this helps someone else because this endeavour was highly time and processor consuming.

[AndreiC]

This is fun. So far I have bricked two processors and it feels like trying to find your keys, in the dark, in a cattle pasture. You blindly keep trying things, but the stuff in your hand isn't quite a set of keys.

Anyway, between the MPC5644 censorship project, and AN3787, I've come up with a project where if I boot my TRK-MPC5634M board with SW2 depressed, it goes into the unlock code. If the switch isn't pressed, I check to see if *0xFFFDD8 == the top half of my key. If the processor seems to be locked, I start a blinky. If the processor isn't locked, I lock the processor.

It appears that if I lock the processor, the processor then resets. An odd result. But it also leaves me with a processor that is censored and doesn't have the default, or my chosen key. Is the reset an expected action?

If I press the button, it goes into the unlock code, then resets, and goes into the unlock code... 

If the button isn't pressed, it goes into the lock code, resets, goes into the lock code... 

Yes, I'm sure that the button works, but it does appear that I can't successfully query the key to see if it has been set.

So I seem to have to arrange for the debugger to jump in after the erase, in that infinitesimally short period when the processor is in a good state, which seems to be never.

Are there any best practices to see if the processor is censored when first firing up? Something that I can check, then bypass censoring for the rest of the life of the code?

I've plopped the whole project down in the doobly-doo. It's set up for S32DS 1.X and running on an MPC5634M on a TRK-MPC5634M.

[AndreiC]

duplicate

[AndreiC]

I guess that I should add that I am using S32DS for powerPC and a P&E Multilink universal.

[lukaszadrapa]

Hi Andrei,

there's no such document but this example could help:

https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/Example-MPC5644A-Censorship-CW210/ta-p/1105016

MPC5644A is very similar to MPC5634M.

And when playing with censorship, my recommendation is: either implement step from mentioned application note AN3787 or write simple application which will be loaded to flash before modifying shadow flash (I think this is easier option). What the application should do: when pressing a button (or receive a command via UART or something like that), it should erase the shadow flash and program default values of censorship words. So, if something goes wrong, you will have easy option to recover.

Regards,

Lukas

[AndreiC]

Hey Luka,

Do I have to execute this code from RAM?

A

[AndreiC]

Okay, so far I've bricked 3 processors, it's like setting $20 bills on fire at this point.

MPC5634M on a TRK-MPC5634M under S32DS for PPC 2017.R1...

The current fragment of code is:

    //unlock shadow block
    CFLASH0.LMLR.R = 0xA1A11111;    //unlock register
    CFLASH0.LMLR.R = 0x800FFFFF;    //unlock shadow flash
    CFLASH0.SLMLR.R = 0xC3C33333;   //unlock register
    CFLASH0.SLMLR.R = 0x800FFFFF;   //unlock shadow flash
    //erase shadow flash
    CFLASH0.MCR.B.ERS = 1;
    *(unsigned int*)0x00FFFC00 = 0x0;    //interlock write - write any address in shadow block
    CFLASH0.MCR.B.EHV = 1;
    while(CFLASH0.MCR.B.DONE == 0) {}
    CFLASH0.MCR.B.EHV = 0;
    CFLASH0.MCR.B.ERS = 0;

I unlock the shadow flash, start the erase, interlock write, then (I think) when I turn on the high voltage, I get an IVOR1 and we're done. The code doesn't get to the while loop, just an IVOR1 (on my next processor I'll get the CSRRx and MSR).

At this point the shadow block is erased, my code is no longer continuing on to setting the passwords or the control words since it takes the IVOR, and the processor is locked.

On my last processor attempt, I tried to set the PC to some code that would write the passwords, and while it was at a breakpoint, I manually set the control words to uncensor everything, but it apparently didn't work and the processor was still censored and bricked.

Is it possible that I cannot use the debugger when trying to get this stuff working? Do I have to write a perfect program from code for a different processor and compiler and hope that it works the first time?

Sorry to sound grumpy, my electronics tech thinks that she might not be able to replace the processor again without lifting traces, and having one attempt per processor is getting old very quickly.

[AndreiC]

Ah, thank you. I was looking at the MPC5604B censorship project, it was a little clearer than the manual. I'll look at the 5644 code as a sample.

I like the idea of the button to uncensor the processor while testing. 

Thanks again,

Andrei