ROB LUND

QT4 security bytes being erased

Discussion created by ROB LUND on Feb 16, 2006
Latest reply on Nov 3, 2006 by bigmac
I'm a FreeGeeks refugee, so I'm here now posting on Freescale's forums. Curiously absent in the forum imports is my lengthy thread on security byte erasure. Have a look at the FreeGeeks archives for reference. There are a bunch of good replies/theories that didn't pan out for me. I'm posting a modified version of that original with all the latest findings:

I'm using both QT2 and QT4 MCU on one common gerber design. My original firmware was designed for the QT2. Newer firmward utilizes the ROM-resident flash programming routines and as a result only fits in the QT4. Same fab is shared between firmware versions.

Symptom:

Under certain environmental conditions, target board fails a standard test. It was discovered that under these conditions, the jump vectors were being erased. As such, since the reset vector was reset to FF, the MCU was attempting to enter monitor mode and thus never executing user code. Curiously, the user code is NEVER affected, only the jump vectors.

Observations:

1) These failures almost seem ESD related. In isolated tests, we've been able to duplicate the failures by simply walking around and then touching the target.

2) The failures are only resident in my new firmware version (which uses the ROM-resident flash programming routines for memory storage).

3) If I load up these same QT4 targets with old firmware (non ROM-resident utilizing versions), I've never witnessed a failure.

4) Even after programming the flash block protect register (FLBPR @ $FFBE) this problem persists, which should be impossible.

5) There is a mask set errata published for the QY4 in which there's a section headed "Page Erase Can Cause Unexpected Erase of a Another FLASH Page". That's a very close theory, but there are some holes:

a) my mask sets are quite newer than those published in the errata
b) I'm not using interrupts
c) I'm resetting the COP often.

Any thoughts?

Outcomes