I have a board with MPC5646C, which is programmed with the default password 0xfeedfacecafebeef. When I try to connect with JTAG, it fails. What I tried:
The device appears to not accept the password shifted via JTAG - when reading the OnCE status after password is being sent, it is set to all zeroes (looked at transactions with logic analyzer). I've lastly used that board months ago and it was working then, I haven't made any notes on weird behavior.
I have a Blinky RAM code which I can send via BAM, and I can see that the code is loading and running fine using the default password mentioned above. I would think that means the password is as expected.However I don't have another MPC5646C which I can use to create a RAM image which modifies the shadow flash.
What could be a possible reason for that situation?
Thanks
Solved! Go to Solution.
No, I am afraid there is no such appnote. It is needed to consult with device's RM.
However I made censorship example for MPC5604B, where it is implemented same way:
https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/Example-MPC5604B-Censorship-CW210/ta-p/1123992
Have you tried to enter reveres password 0xcafebeeffeedface?
On this family it needs to be entered in reverse.
Yes, I am entering the password in reverse.
Which version of CW you are using? I know CW classic (CW2.10) contains PeMicro debugger that it not up to date and censorship does not work properly with some devices.
PeMicro offers their own debugger (called 64K Starter Edition of P&E's PKGPPCNEXUS) that will work U-MULTILINK-FX. Trial version is free (it is needed to be registered and logged in):
http://www.pemicro.com/downloads/download_file.cfm?download_id=194
你好,请问我的pemicro调试器输入install code 没有生成蓝色的registration code 是怎么回事呢
这是别人的界面
这是我的界面
CW Version 5.9.0.
The strange part is that it was working perfectly a few months ago with the same board, and I don't remember doing anything that would affect the censorship. And BAM works with the default password 0xFEEDFACECAFEBEEF.
I tried with PROGPPCNEXUS and another version of ICDPPCNEXUS, no joy. I was hoping to at least find the problem and avoid it in the future (assuming that the problem is not myself).
Haven't you erased shadow flash? Sometimes user do this when they choose shadow flash programming algorithm by chance.
If if is so, there is no change to recover and you will have to replace MCU by new piece.
I got a new MCU, and I wrote a program which runs from RAM and dumps the contents of the shadow flash - it loads successfully on the problematic device via BAM, and spits out the contents of the shadow block - it's empty, just a repeating pattern. I also tried erasing the shadow flash and restoring censorship with the code below. It also loads fine, but looks like it hangs at one of the while(CFLASH_0.MCR.B.DONE == 0) statements.
#define SHADOW_ADDRESS 0x00FFFC00
#define CENSORSHIP_ADDR 0x00FFFDE0
#define SERIAL_BOOT1_ADDR 0x00FFFDD8
#define SERIAL_BOOT2_ADDR 0x00FFFDDC
#define SERIAL_PASSWORD1 0xFEEDFACE
#define SERIAL_PASSWORD2 0xCAFEBEEF
#define LOW_ADDR_KEY 0xA1A11111
#define S_LOW_ADDR_KEY 0xC3C33333
#define LOW_ADDR_SR_UNLOCK 0x800FFFFF
/*******************************************************************************
Erase shadow flash and restore password & censorship
*******************************************************************************/
void DisableCensorship(void)
{
/* enable shadow space */
CFLASH_0.LML.R = LOW_ADDR_KEY; /* unlock register */
CFLASH_0.LML.R = LOW_ADDR_SR_UNLOCK; /* unlock shadow flash */
CFLASH_0.SLL.R = S_LOW_ADDR_KEY; /* unlock register */
CFLASH_0.SLL.R = LOW_ADDR_SR_UNLOCK; /* unlock 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){};
CFLASH_0.MCR.B.EHV = 0;
CFLASH_0.MCR.B.ERS = 0;
/* step2. program the serial boot word */
CFLASH_0.MCR.B.PGM = 1;
W32(SERIAL_BOOT1_ADDR, SERIAL_PASSWORD1);
W32(SERIAL_BOOT2_ADDR, SERIAL_PASSWORD2);
CFLASH_0.MCR.B.EHV = 1;
while(CFLASH_0.MCR.B.DONE == 0){};
CFLASH_0.MCR.B.EHV = 0;
CFLASH_0.MCR.B.PGM = 0;
/* step3. program the censorship control word */
CFLASH_0.MCR.B.PGM = 1;
W32(CENSORSHIP_ADDR, 0x55AA55AA); //interlock write
W32(CENSORSHIP_ADDR+4, 0xffffffff); //interlock write
CFLASH_0.MCR.B.EHV = 1;
while(CFLASH_0.MCR.B.DONE == 0){};
CFLASH_0.MCR.B.EHV = 0;
CFLASH_0.MCR.B.PGM = 0;
}
Here you have it incorrect
Both filed needs to be 0x55AA55AA because of
I modified the code as you suggested, should not have copy/pasted code from AN3787 with so much trust.
However, the first busy loop, after W32(SHADOW_ADDRESS, 0x0), is never exited.
The device I have is MPC5646C.
AN3787 is only valid for MPC55xx and MPC563x. With MPC5646B it works differently.
Thanks
Is there application note specific to MPC5646C? I was under the (wrong) impressing that the code quoted above should work in my case.
No, I am afraid there is no such appnote. It is needed to consult with device's RM.
However I made censorship example for MPC5604B, where it is implemented same way:
https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/Example-MPC5604B-Censorship-CW210/ta-p/1123992