S12 / MagniV MicrocontrollersのトピックRe: Trouble programming FSEC to the recommended secure state

Trouble programming FSEC to the recommended secure state

xgater — Sat, 30 Dec 2006 01:18:05 GMT

CPU: MC9S12XDT256

I am enabling security in my application by programming the address $FF0F to $BD. The problem is that my programmer (P&E Cyclone Pro) fails verification and says that address reads as $BC. According to the CPU user manual, the preferred state of the SEC (least significant) bits to enable security is 01 even though it says that 00 is also secure. If I change my code to set the security byte to $BC, then it passes verification. So, I may leave it that way even though it is not "preferrred". I can't find anywhere in to user manual or app notes that says this one bit can't be left erased or can't be read back.

Does anyone have a clue why this one byte won't verify?

Re: Trouble programming FSEC to the recommended secure state

NLFSJ — Sat, 30 Dec 2006 02:55:36 GMT

Hi,

I don't have an answer on this, you may want to contact P&E. But have the following information for you -if sec1 and sec0 of 0xFF0F is not 10, any other 3 combination will secure HCS12 mcu, i.e for your situation, -- BC, BD and BF should all secure the chip.

Regards,

Nina

Re: Trouble programming FSEC to the recommended secure state

peg — Sat, 30 Dec 2006 05:17:42 GMT

Hi xgater,

I don't know this device, but this sounds very similar to this thread:

http://forums.freescale.com/freescale/board/message?board.id=8BITCOMM&message.id=3649

Hope it helps

HNY!

Regards

Peg

Re: Trouble programming FSEC to the recommended secure state

StephenRussell — Mon, 01 Jan 2007 00:53:54 GMT

I also believe that the referenced thread is about the same problem.

Freescale recommends that you program the security bits to "unsecured" as part of erasing flash. The Freescale recommended 27 step unsecuring method does this. Simple flash programming utilities do this routinely after doing a bulk erase of flash.

If this recommendation is followed, the only value that can be programmed without another erase is 00. Doing this "cumulative programming" violates Freescale recommendations, but does work.

The proper method would be to read the sector containing 0xFOFE, erase it, and program it with the modified values. As far as I can tell, many programming utilities do not consider doing sector reprogramming and don't do this.

Re: Trouble programming FSEC to the recommended secure state

xgater — Thu, 04 Jan 2007 01:17:45 GMT

Thanks. This makes sense now. So, to sum it up....

The SEC bits are set to the unsecure state (10) by the BDM tools because they have to be for BDM access. (duh! I should have realized this on my own.)

This means that the only option for securing the part is to program the other bit resulting in SEC bits 00.

So, the "recommended" value should just be ignored.

I will just set SEC to 00 and all is well.

Thanks, again.