Problems in migrating to 256k part.

[kevinclark]

We are trying to port an application currently running on a MC9S12XD64 to a 9S12XD256, with an intermediate stop at 9S12XDG128.  We are using the 80 pin package.

We are using CodeWarrior, with a P&E Cyclone Pro debugger, with F/W 8.52-1.6.

In programming the object code originally compiled for the 64K into the 128K part, everything works perfectly.  However, in programming the 256K part, we are running into problems.

We have found the random act of engineering committed in changing the PAD[7:0] pins from ATD1 to ATD0.  Fixing that is a small matter of programming.

If we program a virgin 256k part with the original object code, it will properly program and properly operate, except for the ATD issue.  However, it will thereafter fail to unsecure, erase, or program using the Cyclone Pro software.  As far as that is concerned, the part is dead, and we have had to swap it out, twice, to proceed, and changing that 80-pin part is fraught with hazards.

And, although the debugging environment does appear to recognize the part, trying to debug using CW is giving screwy results.

So, my first question is, are there other differences, big or subtle, in migrating to the 256K part?  Do we need to recompile the code for the different part, apart from the ATD issue?

I'm only the hardware engineer, program development is done by our software engineer.

[kef2]

It matters what maskset are all those XD64, XDG128 and XD256 you just mentioned. Chances are XD64 and XDG128 you used are of the same makset and thus have the same (not lower) amount of flash and RAM, are identical.

All 3 devices have different memory maps and it should be taken into account both when linking (proper CW PRM file) and flashing (proper Cyclone / Multilink programming algorithms).

You can't make S12XD part dead while flashing. It is 102% possible to unsecure and reflash your MCUs. Just use proper tools with proper settings. I'm not familiar with Cyclone, but Unsecure12 from P&E makes wonders while using with Multilink.

To debug on XD256 you need proper settings in debugger. No wonder if you have problems debugging XD64 project on XD256 part. At least debugger should be made aware what part are you using.

[kevinclark]

I think we have found the root of this issue. The original designer

used port PEx for the keypad inputs. Since this port also is used for

the MODx bits, the keypad was interfering with the MODx bits, putting

the part into an illegal or expanded mode. With the mode bits properly

set, we are able to properly program the flash. The reason it works

with the 64/128K parts is that the mode definitions have changed between

those and the 256K parts. This is not noted in the "HCS12XD Family

Compatibility Considerations" document.

Thank you for your help.

Kevin W. Clark

Stress-Tek. Inc.

253-480-2230

kevinc@stress-tek.com