AnsweredAssumed Answered

Problems in migrating to 256k part.

Question asked by Kevin Clark on Jun 19, 2014
Latest reply on Jun 20, 2014 by Kevin Clark

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.

Outcomes