Problem with Atmel PAL Power Down?

[W Letendre]

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

 

[Fred Bloggs]

W Letendre wrote:

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

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..

 

[Fred Bloggs]

Fred Bloggs wrote:

W Letendre wrote:

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


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..

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.

 

[Fred Bloggs]

Fred Bloggs wrote:

... PAL reads settled sensor inputs
correctly, ...

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.

 

[W Letendre]

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...

 

[W Letendre]

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

 

[Fred Bloggs]

W Letendre wrote:

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.

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.

Pain that board
are a;ready made. Have about 200 of the things, mostly at customer's
shop...

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