1. Home
  2. Electronics Design
  3. Problem with Atmel PAL Power Down?

Problem with Atmel PAL Power Down?

Using Atmel ATF22V10CZ PAL in servo amp, as Hall sensor decode for motor commutation. Logic is strictly combinational (no clock used, no feedback from outputs to inputs 'cept through motor, via motion). Used power down version of PAL cause Hall state transitions are slow, by electronic standards, and the power savings were nice, if not absolutely necessary.

Problem I'm seeing is, once in a great while, PAL "forgets" to change output state in response to change in Hall lines. Result not too hard to catch, in post mortem, 'cause motor stalls, then waits patiently at "zero torque" point for hapless engineer to attach scope probe to drive PCB. Result is clear: PAL outputs and inputs don't match source code file. But, if you "nudge" motor to next Hall transistion, resumes normal operation ,and PAL pins show expected logic levels, all six legal Hall states, 'till the next failure event.

Was concerned that the rise times on the Hall signals might be too slow for reliable triggering of "Atmel's patented Input Transition Detection (ITD) circuitry" since the Hall sensors are Open Drain devices. So, decreased pull up resistor from 10K to 1K, reduced capacative bypass from 0.1uF to 0.01uF. No help.

Any idea what the gremlin here might be? Should mention, this symptom shows up in about 20% of drives built to date. Going through the exercise now of peeling off checksum labels and checking date codes, to see if we might have a bad batch of PALs!

W Letendre

Reply to
W Letendre
Loading thread data ...

One saving grace with motor Hall sensors is that they are set up so that only one input at a time ever changes; skew should not be a problem. May have to add Schmitt, it it comes to that. Pain that board are a;ready made. Have about 200 of the things, mostly at customer's shop...

Reply to
W Letendre

Interesting suggestion! What is drill for getting PAL output to change state on "active" mode?

Reply to
W Letendre

Nowhere does ATMEL specify a minimum slew rate for the IDT, but you know it has to be relatively fast because all they have to work with internally are gate delays and those aren't much. A second problem you might run into is that there is enough skew between Hall outputs to cause the part to go into active-standby-active etc on a single motor transition- because the Tactive time before power down can be as small as 12ns- that should not bother a purely combinatorial ckt w/o feedback- but it very well may bother the ITD logic if the skew is close to PAL timing boundaries. They say the entire internal fuse array is powered down in standby so that probably means it will not necessarily show the correct programmed output state corresponding to a input state in standby mode if it failed to come out of standby for whatever transition resulted in that input state. If it was just slew rate, a hex Schmitt driving the PAL inputs fixes the problem, but if it's skew matching/control on the sensor inputs then you have real problems- especially since it sounds like you have already produced your boards- that can be fixed too, but not with a single part-by doing things like arranging the sensors for a single sensor transition per whatever event it is you are sensing..

Reply to
Fred Bloggs

I think a cheap fix would be to leave everything where you have it, use a spare output to trigger a one-shot whenever PAL enters active mode, one-shot times out for maximum possible settling time of your sensor inputs ( 250ns ?), then one-shot timeout transition on a spare PAL input causes ITD transition to active mode, PAL reads settled sensor inputs correctly, produces correct outputs, and returns to standby. You figure out the PAL logic for the one-shot, maybe you can get away without adding any external components.

Reply to
Fred Bloggs

I should have added : if it did not read them correctly the first time. So "once in a great while" your inputs glitch the PAL, it produces a little indeterminate blip for 250ns, and is then straightened out.

Reply to
Fred Bloggs

Okay- so assuming you do not have a noise problem , the ATMEL slew rate requirements are reasonable, the Hall sensors already have Schmitt trigger OC drives, and the speed of response of the PAL, this leaves a transmission line termination problem between the sensors and the board. This is the kind of thing that will cause a fast chip to act up with excessive overshoot, undershoot clamp currents, and waveform plateaus in the threshold regions. Have you viewed the waveforms on a scope? It will be the low going edge that causes the most trouble- maybe sending a 50mA current step into the PAL ESD clamps.

Unpopulated boards are not that much of a loss in that quantity.

Reply to
Fred Bloggs

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.