16k Flash Arrays Self-Erased (split of thread "HC12DG128A jumps to wrong adress")

[mawetzel]

We are developing products based on the (very old) MC912DG128ACPVE.

We are facing a 10-30% failure rate on our boards: One or two pages (16k flash arrays) got self-erased after programming with supplier's IC-Tester. Reprogramming these boards is possible.

Erased pages: 0x4000-0x7FFF and/or 0x8000-0xBFFF. Once also the unprotected part of Page 1 (0x8000-9FFF) was erased.

Processor Description:

MC912DG128ACPVE

0L05H

z.B. QQJL0622 / QQHE0601

I didn't find a direct relationship to the errata.pdf.

Reply of

kef (Trusted Contributor):

Hm, 10-30% of bad boards, are you using external memory? Bad flash programming algorithm?

".. one or two pages got lost .." . Does it mean one of 32k flash array got self erased ? If so then check how fast does oscilator start up. Make sure that /RESET is kept low while oscilator isn't stable.

--

---

We do not use external memory. Flash programming algorithm is years old:

• Executed from RAM (copied at startup of bootloader)
• --> Attachment.

Your comment to /RESET and oscillator ... We'll check.

Thank you very much.

Message Edited by mawetzel on 2007-04-1607:02 AM

Message Edited by mawetzel on 2007-04-1607:13 AM

[ChuLee]

Same firmware and hardware (MC912DG128ACPVE ) design for 20+ years. Firmware erased 2~3 arrays for the batch marked QDT2036D (in field job only, cannot repeat in the lab). The QDP2004A batch is the old part and works OK

[kef]

Note that subject is not 100% correct. MC912DG128A has 32k flash arrays, not 16k. One array=2 16kpages.

Alban, right, it should be runaway. But note that it's not a S12 but old 912DG128A. These chips (912DG128x and 912D60x) have Collpitts oscilator which starts quite slowly. And there no more fuses in 912DG/912D against running the code @ unstable clock (what will cause runaway). I had my D60 loosing the flash with MC34064 at /RESET. Replacing MC34064 with some from Dallas-Semi, that was keeping /RESET low for several milliseconds, solved the issue completely. I had no more self erasures after then.

S12 has more fuses against self erasure and I find them very robust.

Regards

[Alban]

Hello,

Usually, when you lose memory it is because of code runaway running erasing routines, or problem in the flash routines.

1- If your code, for a reason or another (stack corruption, madness...) jumps and execute flash erasing routines, you can see part or full memory being erased. To see if that could be the reason, you could remove program/erase routines from the memory or put a Software Interrupt when your code tries and access flash registers. This way you can analyze where the call is coming from.

2- May be your flash programming code is being interrupted or being looped into. It could happen in case of code re-use when only some of the code was copied over and some elements overlooked.

This is a very high failure rate for it to be because of the microcontroller. I haven't looked at the Errata list.

Cheers,
Alban.