HC12DG128A jumps to wrong adress

[mawetzel]

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

I've got ONE exemplar of HC12DG128A that has the following behavior. At a point during startup there's the following code (start12.c):

start12.lst:

 345:        (*_startupData.main)();
0010 4bfb0000     CALL  [_startupData:1,PCR]
0014 20ea         BRA   *-20 ;abs = 0000

after linkage:

0x4236  CALL [0x0003, PC] --> jump into the function at adress [0x423D] = "page 1, 0xADB7"

Executing this command (Step into) yield to jump to "page 1, 0xEDB7".

Loading a different firmware revision:

0x4236  CALL [0x0003, PC] --> jump into the function at adress [0x423D] = "page 1, 0xAA2D"

Executing this command (Step into) yield to jump to "page 1, 0xEA2D".

--> Same behavior.

What is wrong here? Simply one board defect? If this would be the only problem, I would have dropped the board but we are facing a 10-30% failure rate on our boards: One or two pages got lost after programming with supplier's IC-Tester. Reprogramming these boards is possible. Now the question is: Does the upper processor bug relate to our 10-30%failure?

Processor Description:

MC912DG128ACPVE

0L05H

QQJL0622

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

Thanks for your help.

[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 lab). The QDP2004A batch is the old part and works OK

[kef]

Did you check what's in memory at 0x423d. When it jumps to page1, EDB7, is there AD.B7.01 in memory at 423d or indeed ED.B7.01?

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.

[mawetzel]

Thank you.

As it might be of interest to others the flash self-erase-issue is threaded separately under subject

"16k Flash Arrays Self-Erased".

The answer to your question is yes: In the respective memory (0x423D) really were the three bytes

AD B7 01

resp. (different firmware)

AA 2D 01.

[kef]

Then I'm not sure what happens. Looks like CPU got crazy or something makes it unable to read flash memory properly? Overclocked? No more ideas