68332: is there any known sensitivity to 5 volt power supply "brownout"?

[tommctaggart]

Our 68332 boards (or some of them anyway) appear senstive to 5V power supply going down to some intermediate voltage (approximately 3V to 1V) and then returning.

In this case, some of our '332 devices will not come out of reset, and cannot be made to come out of reset unless power is completely taken down (to approximately 0V) and then restored. We could call this a power brownout condition. We feed the '332 an external 16MHZ clock, and both clock and reset inputs are OK. But the '332 is not showing any activity (e.g. no attempt to come up and fetch instructions after reset release).

Any comments or similar experiences?

BTW, we recognize that we could revise our power supply and reset circuit to prevent this (e..g by sensing brownout voltage and forcing the power supply off till it goes to 0V, etc.), but we are trying to gain insight into whether the '332 is knonw sensitve to this, and what is happening internallly to it.

Thanks for any help on this!

[TomE]

I have a 68332-based device here that was designed 14 years ago or so. When I've got more time I'll connect it up to a Variac and see if I can brown it out. I don't know if the switching supply with brown-out or drop out. If it does the latter, that may be why we didn't have any problems with it.

I'd suggest checking to see it isn't getting into BDM mode somehow. You might try attaching a debugger, and see if you can recover a "browned out" unit that way. I doubt if that will help, but it is one data point.

Check your Reset circuitry to make sure it keeps asserting Reset all the way through brownout. If it "releases" the CPU at a low voltage it might cause the problem.

I'd also be suspicious of your external clock. It might "glitch" on power-down and generate illegal clocking (edges too close together) as the power goes down. As a test, see if you can gate the clock with Reset and see if the CPU survives that. Or power the oscillator from a signal derived from the power-on-reset.

I remember a Z80-based device that would lock up if the crystal generated a higher harmonic burst on startup. That wedged the CPU so badly it had to be fully powered off to recover.

Is CLKOUT still running? Is MODCLK OK? Is VDDSYN connected to power or ground (latter recommended when not using PLL). It may be getting into a PLL mode.

> In this case, some of our '332 devices

If you can get some that do and some that don't, you want to find out the differences and then try to make them all like the good ones. Rig up some circuitry to generate a "repeatable brownout", either with a programmable power supply or a signal generator driving a relay to give a repeatable "off time". Then I'd start by capturing and comparing the clock waveforms on good and bad boards during a brownout. Then the RESET signal. Then everything else.

Good luck.

[tommctaggart]

Thanks, Tom, good suggestions, much appreciated! We will work on those.

Our lab reported a valid reset condition over the powerdown ( will recheck that), and FREEZE was not active, so should not have been in debug mode. Not sure about the clock, so we can check that. Do you have any definite knowledge of what clock glitches could do? I would not have expected we’d need to care about that if we were driving reset….

Tom McTaggart

206-310-0783 mobile

520-469-6121 desk

[TomE]

> Do you have any definite knowledge of what clock glitches could do?

Everything inside the CPU is clocked. It is full of internal state machines. My experience with other devices (MCF5329) is that the RESET signal does NOT go into all of these state machines. In the MCF5329, the DRAM controller has to "clock itself out" of any reset states, and some of the states it can get itself into don't seem to have have an exit path.

One way to get these state machines into illegal states is to give them two clock edges too close together.

> I would not have expected we’d need to care about that if we were driving reset….

You would hope so, but... During Reset and while the clock is starting is the most likely time to generate bad clock edges. If you're going to try gating the clock with reset (as a test to see if the problem goes away), you're likely to generate narrow glitches with the gating.

Here's another thing to look for. You may be forcing the chip into "latch-up". If you don't know about this, read up on it:

http://en.wikipedia.org/wiki/Latchup#CMOS_latchup

Do you have any separately powered circuitry that can drive any CPU inputs? Is there any external powered hardware sending signals into CPU I/O ports? Is there any powered circuitry with larger power supply capacitors that may stay near 5V (and be driving 5V into the CPU) while the CPU power rails fall? You're looking for anything that can drive a CPU pin to a higher voltage that the CPU's VDD currently is. This "injection current" can trigger latchup.

Can you measure the CPU current? If it is latched up it may be drawing excess current, or even getting hot. So put your finger on it.

Some CPUs can handle a certain amount of "injection current", and specify this (as per-pin and per-chip maxima) in the Data Sheet. This is especially important in Automotive designs where it is very common to connect CPU pins directly to car battery level signals (meaning 15V) through a 10k to 100k resistor, relying on the CPU's protection diodes to sink the resulting current. That can cause another problem if the total "injection current" is more than the CPU is currently using (if it is in a "sleep mode"). It can push VDD above the maximum allowed.

Hey, nice! The MC68332 Reference Manual specifies the maximum "Digital Input Disruptive Current" of 500uA per pin and 10mA total. This may not apply when "browned out" though.

Tom

[tommctaggart]

Thanks again, Tom, I’d noticed the injection current spec too. We will be out in the lab running these items down…. Will let you know if we find something.