I have a MC9S12A256CPVE microcontroller in a product and I'm writing software using an P&E assembler-debugger-flash programmer through the BDM port.
Currently I'm writing software to test the hardware, and having a problem where when power is applied to the hardware, sometimes a real time interrupt ISR executes, sometimes the main loop executes, and sometimes there is no execution, all with the same simple code which is a very short program which transmits a message from the SCI in a main loop while a real time interrupt is periodically generated with a simple toggle to create a square wave on pk0 - pk7.
I have similar code running on an S12E128CPVE and have never experienced anything like this. I can't get any E128 to do this even with far more complex code.
When I use an older originalMC9S12A128, all things being equal, everything works flawlessly, in fact I have a P&E evaluation board that I tried the part on, and the A256 still malfunctions. When I use the old Motorola part with the exact same code, except for making initram $20 for the a128 instead of $10 for the a256 there are no problems what so ever with either piece of hardware. I then speculated that the a256 was damaged so I pulled out the flawlessly working a128 and installed a brand new a256, and double checked all of the solder joints, the new part fails to enter background mode, and the oscillator does not run. Should there be this many problems between the old and new parts? If so what are the differences between them, and any necessary design upgrades?
I've already toyed with the e-clock output, and immediately get a correct stable pll lock of 15.974MHz using a 3.6864MHz crystal in the colpitts configuration when the new a256 does start, some of them however will not even enter into the background mode or start the oscillator. They also malfunction using a canned 3.6864MHz oscillator on a P&E evaluation board. I'm also using the MCS12DP256B.inc header file.
Reading pages 17 to 34 of the MEBI Manual from the zip file for these parts, taken from the Freescale web-site. These pages seem to indicate that for PE0 and PE1 direction changes are unimplemented in Fig. 3-8 (DDRE) thus making them only configurable as inputs, and that function changes for them are unimplemented in Fig 3-9 (PEAR), thus making them only configurable as /IRQ and /XIRQ. Fig. 3-11 on page 24 it is indicated that the PUPEE bit of the PUCR is set during reset, thus enabling pullups on bits 7 and 4-0 of port E automatically during reset. Checking these pins using a volt meter, they are indeed at +5 volts referenced to Vss after reset. Due to the above information, and also never before experiencing this problem, it's difficult to accept failure to service /IRQ, or /XIRQ as a cause of these problems unless I'm completely missing something.