S12 Flash Protection, Security, and the Backdoor

[dkelly]

Going around in circles trying to retrofit a fielded product. Believe I have finally demonstrated and found documentation confirming our situation is hopeless but want a second opinion. Briefly:

CPU is an S12NE64. The FPROT initial value stored in 0xff0d is 0xc7, protecting 0xf800 through 0xffff from being written or erased. Is there any way from inside the S12NE64 to modify this memory region without physical access to the chip and/or product?

Have no problems updating the contents outside of 0xf800 to 0xffff.

The FSEC initial value stored in 0xff0f is 0xfe which is the "unsecured" value, and apparently not relevant to my problem.

The Backdoor key apparently has nothing to do with protection (against accidental write), only security (locked against copying using a BDM). The backdoor will do nothing to allow me to change 0xf800 through 0xffff from within, even if SEC[1:0] in FSEC was not already 0b10 unsecured.

The FPROT register is essentially moot when running on the BDM. Firmware has no problem updating 0xf800 through 0xffff when running with the BDM attached but fails when BDM is not attached. Is there anything I can do in firmware to make the S12 think a BDM is attached when it is not?

Related problem: There is apparently no way to RESET the CPU from inside if COP is disabled. Someone disabled COP from within our _Startup() which is located in the protected region. This is the primary thing I'm trying to fix with a remote firmware update. If COP was enabled "ARMCOP = 0" promptly trips the COP and produces a RESET. Nobody thought to route an output pin to the RESET pin for software initiated hardware resets.

[kef]

dkelly wrote:
CPU is an S12NE64. The FPROT initial value stored in 0xff0d is 0xc7, protecting 0xf800 through 0xffff from being written or erased. Is there any way from inside the S12NE64 to modify this memory region without physical access to the chip and/or product?

No way. That's possibly only using BDM, when you can reset into special chip modes.

Have no problems updating the contents outside of 0xf800 to 0xffff.

The FSEC initial value stored in 0xff0f is 0xfe which is the "unsecured" value, and apparently not relevant to my problem.

The Backdoor key apparently has nothing to do with protection (against accidental write), only security (locked against copying using a BDM). The backdoor will do nothing to allow me to change 0xf800 through 0xffff from within, even if SEC[1:0] in FSEC was not already 0b10 unsecured.

That's right

The FPROT register is essentially moot when running on the BDM. Firmware has no problem updating 0xf800 through 0xffff when running with the BDM attached but fails when BDM is not attached. Is there anything I can do in firmware to make the S12 think a BDM is attached when it is not?

No.

Related problem: There is apparently no way to RESET the CPU from inside if COP is disabled. Someone disabled COP from within our _Startup() which is located in the protected region. This is the primary thing I'm trying to fix with a remote firmware update. If COP was enabled "ARMCOP = 0" promptly trips the COP and produces a RESET. Nobody thought to route an output pin to the RESET pin for software initiated hardware resets.

Is bootloader at f800-ffff writing write-once COPCTL register with CR0-CR2 bits all 0? If so, then yes, COP can't be enabled in your case.

But there's still one possibility. I think you can reset your chip using clock monitor reset. You should try to disable oscilator self clock mode and then do full stop.  This should cause clock monitor reset. I don't remember details, what register and what bits to write, but I think it's possible.

[dkelly]

---

kef wrote:

dkelly wrote:
Related problem: There is apparently no way to RESET the CPU from inside if COP is disabled. Someone disabled COP from within our _Startup() which is located in the protected region. This is the primary thing I'm trying to fix with a remote firmware update. If COP was enabled "ARMCOP = 0" promptly trips the COP and produces a RESET. Nobody thought to route an output pin to the RESET pin for software initiated hardware resets.

Is bootloader at f800-ffff writing write-once COPCTL register with CR0-CR2 bits all 0? If so, then yes, COP can't be enabled in your case.

But there's still one possibility. I think you can reset your chip using clock monitor reset. You should try to disable oscilator self clock mode and then do full stop.  This should cause clock monitor reset. I don't remember details, what register and what bits to write, but I think it's possible.

---

Yes, thats the first problem. COP is disabled almost immediately in _Startup() which is in the protected region. Have other problems with the old bootloader but appears we'll have to live with them. Fortunately all vectors but the RESET vector are redirected through a jump table low in FLASH allowing most everything to be replaced other than the startup code.

I spent a day or two trying to trick the clock monitor into an unreasonable state. Seemed to me that once its running its too smart to let me do bad things to it. Perhaps that was because I was testing with the BDM attached. If you have code that will trash the clock and trip the clock monitor I would appreciate it.

Oh! Thought of something! The clock monitor interrupt is a RESET that clears the write-once flag protecting COPCTL? I have a redirected vector for the clock monitor interrupt! If my code finds COP disabled I might cause a clock monitor reset and run my _Startup() rather than the old _Startup().

[kef]

Sorry for misleading you! Looks like it's not possible to force clock monitor reset since, like CME bit description says, clock monitor is disabled in Stop Mode (PSTP=0) :smileysad:. And another show stopper is that SCME bit is write once bit. I guess PLL is enabled in your case, so most probably SCME is locked in SCME=1 state.

I'm sure it was possible to force CME reset this way on old 912D60A. The same looks not possible on S12.

[dkelly]

Thanks anyway! What I found was that somebody did their job too well at Motorola/Freescale in making the clock foolproof, at least once its running.