The Case of the Incompatible Processor Upgrade

We were running out of code space in our new board, using a Freescale MC9S12DJ64, with 64KB of flash code space, an 8 channel ADC, and other functions. We had gone to the 128K device, MC9S12XDG128CAA, with no issues, and needed to double that, for reliable in-field code upgrades. So we built up a board using the 256K part, MC9S12XD256CAA, and nothing worked right. We could program it once, and after that the programmer would not program it properly, and the chip had to be removed and replaced. The ADC was reading nonsense values wandering around near 0V. All these parts were in the same 80 pin SMT package, with the same pin assignments.

It was time for a paper chase. Luckily Freescale had published a migration guide, which informed us that the die had two ADCs, and for the package we were using, only one ADC was brought out, but in a random act of engineering, which one it was, was changed between the 128K and 256K parts (From ADC1 to ADC0). Luckily, this could be addressed by a simple change in programming, but did make the upgrade less than a drop-in replacement.

Related Articles:

The second issue was more insidious. The I/O port originally chosen by the original designer (not me), for the keypad was the one used by the microcontroller for memory configuration bits and IRQs. It also happened to be driven by CMOS logic at 12V, for the power on/off circuit. The logic levels were divided down by 1/2 by resistors, but were still feeding 6V into a 3.3V processor. So the keypad was interfering with the memory configuration inputs, but only on the 256K part, not the 64K or 128K parts. The migration guide was mute on any differences in that port or the memory configuration. However, careful comparison of the databooks for the two parts revealed that, in another random act of engineering, the state transition tables between different memory configurations (int/ext/expanded/debug/...) were subtly different, with the result for us, that once the part was programmed, the 256K part was locked out of the on-chip flash, and was trying to program external memory. I got around that, on the prototype, by gimmicking in an unused gate to get the mode bits correct, but the ultimate solution was to reassign the keypad to a different port, and add diodes to isolate the 12V logic from the processor.

But why was the 3.3v processor being driven by 12V logic in the first place? The reason for that goes back to the previous generation of the product, which used an MC68HC11, with an external OTP EPROM (One of the reasons the board was redesigned). On that board, the keypad was fed into the ADC port, which was designed with 12V compliance. The keypad logic also held the state of the on/off switch, held up by a capacitor when the external power was removed. Incidentally, in the redesign, the resistive loading on the outputs of the CMOS drained that capacitor, corrupting the on/off state memory. Adding the isolation diodes to the keypad also fixed that issue.

Kevin Clark has been interested in electronics since the 60's, and has worked in a variety of fields, including telecommunications, computer, consumer, and industrial electronics industries, in design, debug, programming, and support roles.