MPC56xx JTAG fails to connect but BAM works

[tbonkers]

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:

• Two different PE Micro Multilink FX probes
•  FTDI with pyjtag

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

[davidtosenovjan]

Have you tried to enter reveres password 0xcafebeeffeedface?

On this family it needs to be entered in reverse.

[tbonkers]

Yes, I am entering the password in reverse.

[davidtosenovjan]

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

[smallyang]

你好，请问我的pemicro调试器输入install code 没有生成蓝色的registration code 是怎么回事呢

这是别人的界面

这是我的界面

[tbonkers]

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).

[davidtosenovjan]

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.

[tbonkers]

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;		
}

[davidtosenovjan]

Here you have it incorrect

Both filed needs to be 0x55AA55AA because of

[tbonkers]

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.

[davidtosenovjan]

AN3787 is only valid for MPC55xx and MPC563x. With MPC5646B it works differently.

[tbonkers]

Thanks

Is there application note specific to MPC5646C? I was under the (wrong) impressing that the code quoted above should work in my case.

[davidtosenovjan · Accepted 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