MPC56xx RCHW configuration prior to modifying shadow flash

[tbonkers]

I am preparing a piece of code for censoring/uncensoring MPC56xx device based on AN3787. The app note advises to program RCHW before doing anything with the shadow flash, so I wanted to double-check if my understanding is correct. I intend to modify the shadow flash with a code that runs from RAM, and is loaded at address 0x4000_0100.

In order to have a chance of restoring the device if anything goes wrong, I need to program a RCHW at location 0x0000_0000 of code flash. What would the correct value of the RCHW be?

• 0x015A_0000_4000_0000 - VLE bit set, reset vector points to beginning of RAM
• 0x015A_0000_4000_0100 - VLE bit set, reset vector points to where I actually load the code

Currently I have an application in Flash, and took a look into the RCHW. It's 0x015A_015A_0000_361C. It appears that the RHCW does not follow the format recommended by AN3787, because the second 4 bytes are not set to 0000.

Edit: If something goes wrong, and the shadow flash is erased without being reprogrammed, can I load the code in RAM via BAM, given that the RCHW is correct?

I only have one MCU, on which to test, and it's important for me to get it right the first time. I'll appreciate your advise.

Thanks

[lukaszadrapa · Accepted solution]

Hi,

you can use both options: 0x015A_0000 or 0x015A_015A. The point is to have 0x015A half word at address 0x0. The second half word is not taken into account.

Some devices do not allow to have BAM start address at 0x4000_0000, it must be shifted to 0x4000_0100. To ensure compatibility with all MPC56xx, use rather 0x4000_0100.

But notice that there are some differences between MPC56xx devices. The application note talks about MPC55xx and MPC563x. One option is to load "rescue" image by BAM (which is more complicated solution) or you can do that via debugger. But, for example, let's compare MPC5634M and MP5646C:

MPC5634M:

lukaszadrapa_0-1646223291180.png

 MPC5646C:

lukaszadrapa_1-1646223359717.png

So, the debugger cannot be used in case of MPC5646C.

Another option which I used for playing with censorship - I wrote very simple application which reprogrammed the shadow flash back to default state after pushing a button. I loaded it to program flash and then I was changing shadow flash using a debugger or using a RAM project and I tested what was needed. If anything went wrong, I just pushed a button and could start over.

By the way, we have some examples here:

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

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

Regards,

Lukas

[tbonkers]

Many thanks for the examples. I've managed to get the shadow flash erase/write working from RAM using the code in application note.

What's strange is that on one device it worked fine, and on another device the code hung on erasing the shadow flash:

	/* step1. erase shadow row */
	CFLASH_0.MCR.B.ERS = 1;
	W32(SHADOW_ADDRESS, 0x0);					/* interlock write - write any address in shadow block */
	CFLASH_0.MCR.B.EHV = 1;
	while(CFLASH_0.MCR.B.DONE == 0){}; /* Got stuck here */
	CFLASH_0.MCR.B.EHV = 0;
	CFLASH_0.MCR.B.ERS = 0;	

Is there a way for finding and rectifying the reason for the failed erase?

Edit: After reading another thread, I thought that it may be the case that MPU is restricting access to parts of memory - could that be a possible culprit?

[lukaszadrapa]

Hi,

I don't think that MPU is the reason. It's disabled by default or you can check current state by your debugger.

Do you mean it hangs when waiting for DONE bit? What is the content of MCR register at this moment?

Regards,

Lukas