MC9S12A128BCPV new mask = temperature problems

[Grzegorz]

Dear collegues,

I used for my design the MC9S12A128BCPV microcontroller with mask 0L85D. No problems. Design was well tested. Device manufactured for past two years. Now purchasing both microcontrollers with mask 1L59W.

Unit with such microcontroller doesn't work in temperatures below 0. I observe random ROM or RAM errors and get random resets. I have the same symptoms on the bigger quantity of samples. I checked the design again and everything seems ok.

Does anyone faced similar problems with this device? Any suggestions?

TIA

Grzegorz

[Lundin]

For reference, the 1L59W mask works just fine in low temperatures. My company has used that mask for around two years without problems, and we test every single system in -30dgr to +70dgr Celsius. That is, the temperature is immediately switched from -30 to +70, and the other way around. The system is divided in two separate units, so during testing there is one S12 running at
-30 and one running at +70. Without one single problem related to the S12 or this particular mask.

So the problem is obviously not the silicon mask. You should be able to easily verify this by taking a circuit board with problems and replacing the mcu with one of an old mask.

[Grzegorz]

Hello,

Lundin, thanks for the post. I think I found the reason. My XCLKS signal was 1 as defined in S12CRGV3.pdf. Newer documentation says otherwise. Old mask was not sensitive to this.

I'm still testing, but I think this is it.

BTW. Do you know what is a difference between MC9S12A128BCPV and MC9S12A128CPVE?

Apparantly it this is a replacement but "Functionally different". I cannot find what is different 

Regards,

Grzegorz

[Lundin]

The documentation regarding PE7 / XCLKS is very fuzzy indeed, with contradicting values in different versions of the datasheets. I don't trust the datasheets anymore for that particular case, but look at a handwritten note on the wall next to my desk

Pulled high = Colpitts
Pulled low = Pierce or external

If wrong oscillator selection is the problem, you should be able to see it by measuring the oscillator frequency. If it is somewhere around 2-3MHz, the chip is running in self-clock mode ("limp home"). In that case, you might want to rewrite your program so that you get an error notification in case of self clock mode.


Partnumber:
MC = Motorola/Freescale
9 = Flash-based mcu
S12 = CPU name
A = Derivate
128 = Flash size
B = Using a buggy old mask, either 0L85D or 1L85D. Contains plenty of silicon bugs, see errata.
C = Commerical temperature -40 to +80 dgr C.
PV = 112 pin LQFP.
E = "Environment", ie RoHS compatible


Edit: By the way, the earliest Dx256 masks did not support Pierce oscillator, while the Dx128 did. This was pretty much undocumented, you could notice it by the absence of pierce oscillator documentation in the Dx256 manual, but since the manual-writers messed up with copy/paste when they did the manuals for the other derivates, the mentioning of Pierce in the manual was rather arbitrary. It should be fixed in newer manuals, and every new mask supports Pierce, but perhaps something similar could be the cause of your problems. I'm not sure if the early S12A masks supported Pierce or not.

Message Edited by Lundin on 2007-10-10 12:54 PM

[Alban]

Hello,

A bit over-simplified to my taste...

It's just a matter of understanding /XCLKS and XCLKS are complement.
That was the error in this case.
Even if I can understand it's not straight forward, here the documentation was right.

Cheers,
Alban.

[Lundin]

No, it is not just the inverted signal. Here is straight from the S12DG128 manuals:

Device UG p66:

"Figure 2-5 Colpitts Oscillator Connections (PE7=1)"
"Figure 2-6 Pierce Oscillator Connections (PE7=0)"

Oscillator manual p11-12:

"Figure 2-1 Colpitts Oscillator Connections (XCLKS=0)"
"Figure 2-2 Pierce Oscillator Connections (XCLKS=1)"



Device UG p77:

"Table 4-2 Clock Selection Based on PE7

PE7 = /XCLKS Description
1 Colpitts Oscillator selected
0 Pierce Oscillator/external clock selected"


Oscillator manual p12:

"Table 2-1 Clock Selection Based on XCLKS

XCLKS Description
0 Colpitts Oscillator selected
1 Pierce Oscillator/external clock selected"


To spice things up further, the signal can have up to 4 different names through the manuals:
PE7, /XCLKS, XCLKS and NOACC.

Message Edited by Lundin on 2007-10-10 02:56 PM

[Alban]

Hello Grzegorz,

Both MCUs are tested to work down to -40°C, therefore I would like to check a few things with you.

Random ROM errors (here flash), is also sometimes called bit-flip when you have one/several bits of byte reverting to their state before programming.
The common reason is wrong flash programming timing which makes the flash cell not contain enough electrical charges. And, through normal charge migration, will make the level of the bit-cell changing after some time.

RAM errors cannot happen like that, even at 0°C. Common RAM corruption comes from low voltage condition or erratic code execution (like code runaway or stack corruption).

Random Resets is difficult to predict and debug through. And, because of the other 2 problems mentioned, I would expect Resets to occur. I mean, if the ROM and RAM are corrupted, the code is likely to be corrupted and therefore the CPU will either execute an illegal Opcode or will jump to an illegal address, both generating a reset.

For all these reasons, I would first concentrate on the Flash corruption, then look at the RAM and finally consider the Resets.

- Can you give us an idea of the number of pieces failing and total number of pieces ?
- Can you show us the oscillator you use ? (Unlikely to cause the trouble though)
- Also, do you use in-circuit Flash programming in your application ?
    - If yes, can we cross-check the timing configuration with you ? (Clock divider vs. Bus/PLL clock)
- Which programmer do you use ? (brand + model + Revision + Software name)

Cheers,
Alban.

PS: if you chose to also enter a Service Request, may you please send me the reference number via Private Message so I can keep both discussions synchronized ?

[Grzegorz]

Alban,

Thank you very much for the prompt reply.

>>- Can you give us an idea of the number of pieces failing and total number of pieces ?

over hundred assembled with a new mask, all showing problem. with old mask - several hundreds produced, no problem.
>>- Can you show us the oscillator you use ? (Unlikely to cause the trouble though)

I used external programmable Epson oscillator 18.432MHz
>>- Also, do you use in-circuit Flash programming in your application ?

in circuit
>>- If yes, can we cross-check the timing configuration with you ? (Clock divider vs. Bus/PLL clock)

now, I don't understand very well how that could be related to the problem. over 0 the device works perfectly OK. So how the programming method could affect the operation below 0?

>>- Which programmer do you use ? (brand + model + Revision + Software name)
Prog12Z with P&E Cyclone Pro

This is a good idea to create a service request. Thanks.

Best regards,

Grzegorz

[Alban]

Thanks for the additional info.

100% fall-out, even if very bad for your production is very helpful for the problem resolution.
I strongly advise the SR indeed as it is not marginal.

When your application is using in-circuit Flash programming, the flash programming state machine needs to get a proper clock for the charge pump.
This charge pump generates the appropriate "high"-voltage to program/erase the cells.
If the timing is not respected, the flash content can change over time and/or temperature. That is a matter of current passing through the transistor cell. This current is influenced by voltage and temperature and the cell can be read at a different level than programmed.

Please attach to your Service Request the INITIAL S-Record (=S19 you programmed to the Flash) and the LOW TEMPERATURE S-Record (=S19 you read back as being corrupted).
Also include your programming/erasure routine code source to be able to differentiate if it is a hard or soft problem.

Cheers,
Alban.