MC9S12A256CPVE problems.

[none_3710978]

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 original Motorola MC9S12A128, 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.

Thanks
Neil

[Lundin]

Some things to check:

- Pull up on the BDM pin? (MODC) Pull up on the reset pin?

-Please note that the pull-up values on PORTE in PUCR applies to GPIO only, and that some pins of the port are not set as GPIO out of reset! Instead you have various mode selections active out of reset, and those ignore the PUCR pull-ups. Therefore you need to check that PE7 is pulled-up / tied to 5V. This pin selects the Colpitts oscillator.

To aid you in your task of pulling that pin correctly, Freescale has released some contradicting manuals, some stating that Colpitts = 0V and some other manuals stating that Colpitts = 5V. As Freescale aren't able to properly document their own pin assignments, use trial & error instead.

- What value do you have on the decoupling cap on the reset pin? The S12 wants a steep reset edge, and any value larger than 100pF should be avoided or you may get problems similar to those you describe. It may just be superstition, but I believe that the older S12 parts are particularly picky with this.

[none_3710978]

Thanks much for taking the time to help me with these problems.

I did finally resolve most of the issues.

First I erroneously stated that the oscillator was of the colpitts configuration.  It is not.  It is the pierce configuration, and I do and did have the xclks pin pulled low using a 10K resistor.

The problems with the clock were being caused by a floating vregen pin, which when connected to Vdd, eliminated that problem.  Surprisingly the older MC9S12A128CPVE (Motorola Logo) worked fine in spite of vregen floating.  With the newer MC9S12A256CPVE (Freescale Logo) some worked, and some had 0 Volts on the 2.5 V pins.

I stated in an earlier post that /irq and /xirq were high out of reset.  This tured out to be true only part of the time. at other times  they were around 1.7volts, but in either case the parts malfunctioned except fot the older parts having the Motorola Logo.

On all of the newer MC9S12A256CPVE (Freescale Logo) the first line of assembly code needed to be a write pucr, enabling the internal pullup resistors for port e (pupee).  On the pierce hardware, this was all that was necessary to facilitate correct operation.  On the P&E DEV9S12A/B with the canned oscillator it was necessary to do this and to add 10K pullups to both /irq and /xirq.

I did not test all of the newer parts uniformly as I do not have zif or clamshell sockets, and need to desolder and re solder to do this, so some may behave a little differently.

A problem with the pierce hardware is that if I connect the external pullup resistors to /irq and /xirq, then one of them will not work with the out of reset conditions.  I did not try changing the irqen register contents yet to fix this.  If I leave the external pullups out of this circuit, and activate the internal pullups via pucr/pupee, then it  works normally, and both /irq and /xirq function.  I did not try all of the modes on the DEV9S12A/B, and did not identify which interrupt failed to work on the pierce hardware.  For my current product, I do not use /irq or /xirq.

The only problem remaining to be resolved is that when using P&E  ICDS12 and executing it's target hardware reset command, the target hardware will then halt with the program counter at $0001, instead of running at full clock speed and displaying watch variables as it's supposed to unless the power to the target hardware is cycled off then on again each time the command is invoked.  Currently P&E is investigating this for me, but you may have some other suggestions.

Again many thanks to all who have read, considered, and(or) answered this post.

[none_3710978]

The only problem remaining to be resolved is that when using P&E  ICDS12 and executing it's target hardware reset command, the target hardware will then halt with the program counter at $0001, instead of running at full clock speed and displaying watch variables as it's supposed to unless the power to the target hardware is cycled off then on again each time the command is invoked.  Currently P&E is investigating this for me, but you may have some other suggestions.

Sorry, I mis-worded this. It should read:

The only problem remaining to be resolved is that when using P&E  ICDS12 and executing it's target hardware reset command, and then executing a run command,  the target hardware will then halt with the program counter at $0001, instead of running at full clock speed and displaying watch variables as it's supposed to unless the power to the target hardware is cycled off then on again each time the reset command is invoked.  This is not a problem on the Motorola Logo parts running the same code. Currently P&E is investigating this for me, but you may have some other suggestions.

[kef]

Do you have voltage supervisor chip connected to S12A RESET pin? S12E has internal low voltage reset circuit, S12A - doesn't have one and you need external one.

To find chip differences read part maskset number (should be printed on chip) and look for maskset errata on freescale.com. If BDM access is working, also try reading PARTID register and verify if it matches your maskset.

[none_3710978]

Yes, all of my hardware platforms use the MC34164.