QT4 security bytes being erased

[irob]

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?

[bigmac]

Hello iRob,

I have some problem with your usage of -

BRCLR mFLCR_MASS,aCTRLBYT,AMBS
The value of mFLCR_MASS is defined in MC68HC908QT4.inc as:
mFLCR_MASS: equ %00000100

The BRCLR instruction for the HC9(S)08 actually requires a bit number, and not a bit mask.  However, since you are writing your own code for a page erase function only, you could simply omit this part of the code.

Do you load your new routine into RAM, and run it from there?  If not, this would account for the operation hanging.

Since the page erase process is timing critical for the HC908, I don't believe you should attempt to single step the code after the HVEN bit is set - if my understanding is correct, this might damage the flash.

Regards,

Mac

[irob]

---

bigmac wrote:

The BRCLR instruction for the HC9(S)08 actually requires a bit number, and not a bit mask...If you are defining MASSBIT specifically for the CTRLBYT resister, the definition should be (refer Table 4 of AN1831) -

MASSBIT equ 6

Ahh, this was just my misunderstanding of the CTRLBYT. I'm not real clear why you say I can just omit the BRCLR's though. I suppose because I'm only ever doing page erases and never mass erases?

---

bigmac wrote:

Do you load your new routine into RAM, and run it from there? If not, this would account for the operation hanging.

Currently, no I am not. As I recall, this was true of the erase functions for the 9S08 family, but I didn't realize it held true for the 908's. I take it, it's expressly because I'm writing my own erase routine? I mean, it works to call the ROM-resident version without copying it to RAM first.

Regardless, I'll set to work copying/calling it to/from RAM.

---

bigmac wrote:

the DELNUS subroutine is called within ERARNGE, using relative addressing. If you wish to continue using the ROM based DELNUS you will need to change the calls from BSR to JSR.

Yes, I'm continuing to use the DELNUS out of ROM and have already found the BSR/JSR problem. The compiler gave me errors for the relative addressing.

Thanks for all your help and source code!

[irob]

Big Mac, have you had any luck with the "Workaround Code" at the end of AN1831? It appears to copy the Page Erase portion of ERARNGE into RAM and then executes it there.

Anyone else using this yet?

[bigmac]

Hello iRob,

The flash programming and erasing operations for the HC908 must run from either RAM or ROM since the flash memory becomes inaccessable during these operations.  In this respect it is similar to the 9S08 devices.

Actually, I have never used any of the devices that requre the "workaround code", and as I have previously said, I have not experienced your problems with the QT/QY series.  A further possibility might be to load the erase routine to the stack - I recall that I have seen such references in this forum pertaining to 9S08s.

Regards,

Mac

[bigmac]

Hello iRob,

Further to my previous post, there is another reason why the ROM based code for ERARNGE cannot be directly loaded to RAM, without modification.  This is because the DELNUS subroutine is called within ERARNGE, using relative addressing.  If you wish to continue using the ROM based DELNUS, and there is no reason not to do so, you will need to change the calls from BSR to JSR.  This will also affect the macro definition for DEL_NUS, if you are still using it.

To clarify a further point of confusion concerning the mass erase control bits - the bit designated as MASS is defined for the FLCR register (and not the CTRLBYT register at RAM+8).  If you are defining MASSBIT specifically for the CTRLBYT resister, the definition should be (refer Table 4 of AN1831) -

MASSBIT  equ  6

In the attached file, I have shown the ERARNGE subroutiine based on the same ROM routine, but stripped of the mass erase code to give page erase only.  I have also eliminated the macros previously use, that seem to be causing some confusion.  I have also chosen to explicitly clear the ERASE, MASS and HVEN control bits, rather than toggle them, as the ROM code does.  You could actually clear the MASS and ERASE bits using a single mask, and save two bytes of code.

Regards,

Mac

Message Edited by bigmac on 2006-11-0209:09 PM

[bigmac]

Oops!  I missed one of the instances of altering BSR to JSR.  The corrected code is attached.

Regards,

Mac

[irob]

A followup:

I've now tried simply using Big Mac's erase function but can't but my debugger gets lost midway through it. I've also implemented Tonyp's corrections, but still no luck.

Mac, any thoughts?

[irob]

Alban, in a sampling of 4 such target boards, here's what I see under a microscope:

MCQ4C RMAE515
MQ4ME RMCGWm
MQ4ME RMCGWm
MQ4ME RMCGWm

[Alban]

Sorry iRob,

I don't understand these markings.

Alban.

[Alban]

Hi iRob,

Looks like a good guess to me.
Check how they are being handled in the soft, but these are indeed bits in the Flash.

Alban.

[irob]

Sorry, Alban, I haven't had much time lately to respond. I have three (three!) simultaneous production runs happening.

But quickly, I just got some new info from my local distributor about updated Freescale docs:

AN1831 using MC68HC908 On-Chip FLASH Programming Routines
AN2874 Using M68HC908 ROM-Resident Routines
AN2874SW CodeWarrior 5 demo software for both the HC908QY4 and HC908LJ12

Looks promising...

[JM]

I have a similar problem  with a DemoBoard. The mask is ZRPG.

When I erase a page at $EE00, 16 bytes are being erase at $FFB0.

I can reproduce this, every time I try it.

 I use  ERARNGE rom routine to erase the page.

When I use mask ZRQG with the same software, everything is alwright.

It looks it's a bad mask just like 3L69J !

It would be fine to have a compilation of those faulty masks.