wacky clocking of 74HC4017 - help!

[budgie]

I have a bizarre clocking situation occurring with a 74HC4017 which is
being clocked from the PC parallel port.

Conditions: CLK1 (- edge-triggered) tied to 0V. CLK0 (+ve
edge-triggered) is low. There is an additional 10k pullup to help the
O/C LSTTL line driving CLK0 pull up to near 5V.

The reset pin, intially held high, is dropped to 0v. 4017Q0 shows 1
(as it should). On the next rising edge of CLK0, the '4017 advances
to Q2=1. On each subsequent rising edge, the counter advances by one,
yet on that first edge it always advances by two, from Q0 to Q2.

The clock pulses, from the LPT1: control register, show a clean
transition each time.

I'm not what you'd call new at this stuff, but this one has got me
burgered. Other than a wacky HC4017, any suggestions?

 

[David L. Jones]

On Mon, 22 Sep 2003 08:54:27 GMT, budgie
<budgie@nowhere.cantech.net.au> wrote:

I have a bizarre clocking situation occurring with a 74HC4017 which is
being clocked from the PC parallel port.

Conditions: CLK1 (- edge-triggered) tied to 0V. CLK0 (+ve
edge-triggered) is low. There is an additional 10k pullup to help the
O/C LSTTL line driving CLK0 pull up to near 5V.

The reset pin, intially held high, is dropped to 0v. 4017Q0 shows 1
(as it should). On the next rising edge of CLK0, the '4017 advances
to Q2=1. On each subsequent rising edge, the counter advances by one,
yet on that first edge it always advances by two, from Q0 to Q2.

The clock pulses, from the LPT1: control register, show a clean
transition each time.

I'm not what you'd call new at this stuff, but this one has got me
burgered. Other than a wacky HC4017, any suggestions?

The usual culprit in this situation is of course clock bounce/ringing.
But if you checked for this right at the input pin with a scope, the
other usual culprit is too slow a transition of your input clock. In
this case caused by your O/C output, long line, and pull up resistor.
74HC devices can have a maximum rise and fall time for the inputs, if
you exceed this you can have problems. From memory it's in the order
of 500ns max at 5V, but that does vary a lot. A schmitt buffer before
your clock input should do the trick.

Hope that helps.

Regards
Dave
---------------------------
(remove the "_" from my email address to reply)

 

[Unbeliever]

"budgie" <budgie@nowhere.cantech.net.au> wrote in message
news:3f6eb862.19886017@news.cantech.net.au...

I have a bizarre clocking situation occurring with a 74HC4017 which is
being clocked from the PC parallel port.

The clock pulses, from the LPT1: control register, show a clean
transition each time.

I'm not what you'd call new at this stuff, but this one has got me
burgered. Other than a wacky HC4017, any suggestions?

1) Check that you have VCC, and Ground connected. These guys can exhibit
bizarre behaviour when powered via the protection diodes on the inputs.

2) Check that your decoupling is existant and adequate.

HTH,
Alf

--
Alf Katz
alfkatz@remove.the.obvious.ieee.org
www.micromagic.net.au



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.516 / Virus Database: 313 - Release Date: 1/09/2003

 

[budgie]

On Mon, 22 Sep 2003 22:16:15 +1000, "Unbeliever"
<alfkatz@remove.the.bleedin.obvious.ieee.org> wrote:

"budgie" <budgie@nowhere.cantech.net.au> wrote in message
news:3f6eb862.19886017@news.cantech.net.au...
I have a bizarre clocking situation occurring with a 74HC4017 which is
being clocked from the PC parallel port.

The clock pulses, from the LPT1: control register, show a clean
transition each time.

I'm not what you'd call new at this stuff, but this one has got me
burgered. Other than a wacky HC4017, any suggestions?

1) Check that you have VCC, and Ground connected.

Yep, sure have.

These guys can exhibit
bizarre behaviour when powered via the protection diodes on the inputs.

I know - I have one proprietary "trick" where I can "half-disable" a
4174 latch by removing the +5V

2) Check that your decoupling is existant and adequate.

Yep.

Tnx for the suggestions.

 

[budgie]

On Mon, 22 Sep 2003 11:02:20 GMT, tronnort_@yahoo.com (David L. Jones)
wrote:

On Mon, 22 Sep 2003 08:54:27 GMT, budgie
budgie@nowhere.cantech.net.au> wrote:

I have a bizarre clocking situation occurring with a 74HC4017 which is
being clocked from the PC parallel port.

Conditions: CLK1 (- edge-triggered) tied to 0V. CLK0 (+ve
edge-triggered) is low. There is an additional 10k pullup to help the
O/C LSTTL line driving CLK0 pull up to near 5V.

The reset pin, intially held high, is dropped to 0v. 4017Q0 shows 1
(as it should). On the next rising edge of CLK0, the '4017 advances
to Q2=1. On each subsequent rising edge, the counter advances by one,
yet on that first edge it always advances by two, from Q0 to Q2.

The clock pulses, from the LPT1: control register, show a clean
transition each time.

I'm not what you'd call new at this stuff, but this one has got me
burgered. Other than a wacky HC4017, any suggestions?

The usual culprit in this situation is of course clock bounce/ringing.
But if you checked for this right at the input pin with a scope, the
other usual culprit is too slow a transition of your input clock. In
this case caused by your O/C output, long line, and pull up resistor.
74HC devices can have a maximum rise and fall time for the inputs, if
you exceed this you can have problems. From memory it's in the order
of 500ns max at 5V, but that does vary a lot. A schmitt buffer before
your clock input should do the trick.

Dave, I appreciate the thoughts. But before posting (and exposing
myself to flak) I did a fair amount of testing and thunking.

The real brain-teaser - and the reason I think it is something "else"
- is that all subsequent clocking is normal, no glitches or bounces.
I am single-stepping the code so there is no (timing) reason why the
first -/+ transition should be seen by the HC4017 input as anything
different from the next three or four, yet they are all one step per
-/+ transition. The only thing that IS different is the history ie.
the chip came out of reset some time (seconds) earlier.

One thing I thought of overnight but haven't implemented yet is to
come out of reset with CP0 high, then lower it. That should clear the
history cobwebs and make the first -/+ transition look more like the
second etc.

I don't think I'm a vitim of the little note on Fig 10 (p12/12) in the
Philips data sheet for the HC4017 which states:

"It is essential not to enable the counter on /CP1when CP0 is HIGH, or
on CP0 when /CP1 is LOW, as this would cause an extra count."

 

[Mike Harding]

On Mon, 22 Sep 2003 08:54:27 GMT, budgie
<budgie@nowhere.cantech.net.au> wrote:

I have a bizarre clocking situation occurring with a 74HC4017 which is
being clocked from the PC parallel port.

Try replacing (just) the clock line with with a debounced
push button and see if it still happens. That will, more or
less, indicate if it's hardware or software.

Can you see a short high on Q1 during that time?

There is a "minimum reset removal time - tREM" of about
25nS specified None of the timing diagrams show exactly
what that is but I assume it's what it sounds like?

I can't see anything in either the ST or National datasheets
which might account for it.

Try replacing with a CD4017 and see if it still happens.

I know you're no newbie but are you really _really_ sure
about ground bounce etc? I had a goodie once I couldn't
see until I got my hands on a $30,000 Le Croy

Keep us informed of your progress please.

Mike Harding

 

[budgie]

On Tue, 23 Sep 2003 12:20:34 +1000, Mike Harding
<mike_harding1@nixspamhotmail.com> wrote:

On Mon, 22 Sep 2003 08:54:27 GMT, budgie
budgie@nowhere.cantech.net.au> wrote:

I have a bizarre clocking situation occurring with a 74HC4017 which is
being clocked from the PC parallel port.

Try replacing (just) the clock line with with a debounced
push button and see if it still happens. That will, more or
less, indicate if it's hardware or software.

Can you see a short high on Q1 during that time?

There is a "minimum reset removal time - tREM" of about
25nS specified None of the timing diagrams show exactly
what that is but I assume it's what it sounds like?

I can't see anything in either the ST or National datasheets
which might account for it.

Ni moi non plus, looking at the Philips sheet.

The thing that has got me .. er, puzzled, is that (as posted in
responses elsewhere) it is ONLY the first lo-hi transition after
reset release that causes the double-clocking effect. And as I am
still at the stage of single-stepping the software, the reset is gone
some seconds before the first lo-hi CP0 transition.

Try replacing with a CD4017 and see if it still happens.

Now I wish I had used sockets :-(

I know you're no newbie but are you really _really_ sure
about ground bounce etc? I had a goodie once I couldn't
see until I got my hands on a $30,000 Le Croy

As sure as I can be without that sort of budget.

Keep us informed of your progress please.

Will do, even it is totally embarassing.

 

[Mike Harding]

On Mon, 22 Sep 2003 08:54:27 GMT, budgie
<budgie@nowhere.cantech.net.au> wrote:

I have a bizarre clocking situation occurring with a 74HC4017 which is
being clocked from the PC parallel port.

Conditions: CLK1 (- edge-triggered) tied to 0V. CLK0 (+ve
edge-triggered) is low. There is an additional 10k pullup to help the
O/C LSTTL line driving CLK0 pull up to near 5V.

Just one other thought:

My data sheets describe the 4017 as having 1 clock and
1 clock enable (as opposed to 2 clocks) the logic diagram
suggests there is not much difference between them though.
Might just be worth swapping them around to see if it makes
any difference. The technical term for this is "clutching at
straws"

Mike Harding

 

[budgie]

On Tue, 23 Sep 2003 14:29:07 +1000, Mike Harding
<mike_harding1@nixspamhotmail.com> wrote:

On Mon, 22 Sep 2003 08:54:27 GMT, budgie
budgie@nowhere.cantech.net.au> wrote:

I have a bizarre clocking situation occurring with a 74HC4017 which is
being clocked from the PC parallel port.

Conditions: CLK1 (- edge-triggered) tied to 0V. CLK0 (+ve
edge-triggered) is low. There is an additional 10k pullup to help the
O/C LSTTL line driving CLK0 pull up to near 5V.

Just one other thought:

My data sheets describe the 4017 as having 1 clock and
1 clock enable (as opposed to 2 clocks) the logic diagram
suggests there is not much difference between them though.

To my bleary eyes, the logic diagram suggests NO difference in the
function of the and gate vis--vis the two clock inputs.

Might just be worth swapping them around to see if it makes
any difference. The technical term for this is "clutching at
straws"

I prefer the term exhaustive anaylysis/testing ;-)

 

[Mike Harding]

On Tue, 23 Sep 2003 07:41:05 GMT, budgie
<budgie@nowhere.cantech.net.au> wrote:

On Tue, 23 Sep 2003 14:29:07 +1000, Mike Harding
mike_harding1@nixspamhotmail.com> wrote:

On Mon, 22 Sep 2003 08:54:27 GMT, budgie
budgie@nowhere.cantech.net.au> wrote:

I have a bizarre clocking situation occurring with a 74HC4017 which is
being clocked from the PC parallel port.

Conditions: CLK1 (- edge-triggered) tied to 0V. CLK0 (+ve
edge-triggered) is low. There is an additional 10k pullup to help the
O/C LSTTL line driving CLK0 pull up to near 5V.

Just one other thought:

My data sheets describe the 4017 as having 1 clock and
1 clock enable (as opposed to 2 clocks) the logic diagram
suggests there is not much difference between them though.

To my bleary eyes, the logic diagram suggests NO difference in the
function of the and gate vis--vis the two clock inputs.

One of them has an inverter and the other doesn't,
depends how you draw the internal logic as to which
one though.

Have you tried the push button replacement for the
clock in order to rule out/in the software?

Mike Harding

 

[David L. Jones]

On Tue, 23 Sep 2003 01:32:26 GMT, budgie
<budgie@nowhere.cantech.net.au> wrote:

On Mon, 22 Sep 2003 11:02:20 GMT, tronnort_@yahoo.com (David L. Jones)
wrote:

On Mon, 22 Sep 2003 08:54:27 GMT, budgie
budgie@nowhere.cantech.net.au> wrote:

I have a bizarre clocking situation occurring with a 74HC4017 which is
being clocked from the PC parallel port.

Conditions: CLK1 (- edge-triggered) tied to 0V. CLK0 (+ve
edge-triggered) is low. There is an additional 10k pullup to help the
O/C LSTTL line driving CLK0 pull up to near 5V.

The reset pin, intially held high, is dropped to 0v. 4017Q0 shows 1
(as it should). On the next rising edge of CLK0, the '4017 advances
to Q2=1. On each subsequent rising edge, the counter advances by one,
yet on that first edge it always advances by two, from Q0 to Q2.

The clock pulses, from the LPT1: control register, show a clean
transition each time.

I'm not what you'd call new at this stuff, but this one has got me
burgered. Other than a wacky HC4017, any suggestions?

The usual culprit in this situation is of course clock bounce/ringing.
But if you checked for this right at the input pin with a scope, the
other usual culprit is too slow a transition of your input clock. In
this case caused by your O/C output, long line, and pull up resistor.
74HC devices can have a maximum rise and fall time for the inputs, if
you exceed this you can have problems. From memory it's in the order
of 500ns max at 5V, but that does vary a lot. A schmitt buffer before
your clock input should do the trick.

Dave, I appreciate the thoughts. But before posting (and exposing
myself to flak) I did a fair amount of testing and thunking.

The real brain-teaser - and the reason I think it is something "else"
- is that all subsequent clocking is normal, no glitches or bounces.

But have you actually measured the rise time of your input clock?
With an O/C output and pullup you could have a slow rising clock, that
will screw things up, even it's as smooth as a babies butt.
Please measure it for me, I need closure! :->

I am single-stepping the code so there is no (timing) reason why the
first -/+ transition should be seen by the HC4017 input as anything
different from the next three or four, yet they are all one step per
-/+ transition. The only thing that IS different is the history ie.
the chip came out of reset some time (seconds) earlier.

One thing I thought of overnight but haven't implemented yet is to
come out of reset with CP0 high, then lower it. That should clear the
history cobwebs and make the first -/+ transition look more like the
second etc.

I don't think I'm a vitim of the little note on Fig 10 (p12/12) in the
Philips data sheet for the HC4017 which states:

"It is essential not to enable the counter on /CP1when CP0 is HIGH, or
on CP0 when /CP1 is LOW, as this would cause an extra count."

Yep, that's par for the course with these selectable edge inputs. Trap
for young players who don't look at the internal circuit to check
whats going on. The multiple labling of the extra clock between
manufacturers is a real pain. The 4017 ain't the only chip with this
same problem.

Regards
Dave
---------------------------
(remove the "_" from my email address to reply)

 

[budgie]

On Tue, 23 Sep 2003 18:14:26 +1000, Mike Harding
<mike_harding1@nixspamhotmail.com> wrote:

On Tue, 23 Sep 2003 07:41:05 GMT, budgie
budgie@nowhere.cantech.net.au> wrote:

On Tue, 23 Sep 2003 14:29:07 +1000, Mike Harding
mike_harding1@nixspamhotmail.com> wrote:

On Mon, 22 Sep 2003 08:54:27 GMT, budgie
budgie@nowhere.cantech.net.au> wrote:

I have a bizarre clocking situation occurring with a 74HC4017 which is
being clocked from the PC parallel port.

Conditions: CLK1 (- edge-triggered) tied to 0V. CLK0 (+ve
edge-triggered) is low. There is an additional 10k pullup to help the
O/C LSTTL line driving CLK0 pull up to near 5V.

Just one other thought:

My data sheets describe the 4017 as having 1 clock and
1 clock enable (as opposed to 2 clocks) the logic diagram
suggests there is not much difference between them though.

To my bleary eyes, the logic diagram suggests NO difference in the
function of the and gate vis--vis the two clock inputs.

One of them has an inverter and the other doesn't,
depends how you draw the internal logic as to which
one though.

That's the only difference, though. Treated as a pair of inputs, they
function the same as the pair on t'other chip.

Have you tried the push button replacement for the
clock in order to rule out/in the software?

Not yet, but I will. And I have single-stepped the software with
breakpoints everywhere so I am extremely confident it isn't software.

But I keep coming back to the fact that only the FIRST transition has
the problem. Now software COULD do that ....

 

[budgie]

On Tue, 23 Sep 2003 09:56:39 GMT, tronnort_@yahoo.com (David L. Jones)
wrote:

On Tue, 23 Sep 2003 01:32:26 GMT, budgie
budgie@nowhere.cantech.net.au> wrote:
On Mon, 22 Sep 2003 11:02:20 GMT, tronnort_@yahoo.com (David L. Jones)
wrote:

On Mon, 22 Sep 2003 08:54:27 GMT, budgie
budgie@nowhere.cantech.net.au> wrote:

I have a bizarre clocking situation occurring with a 74HC4017 which is
being clocked from the PC parallel port.

Conditions: CLK1 (- edge-triggered) tied to 0V. CLK0 (+ve
edge-triggered) is low. There is an additional 10k pullup to help the
O/C LSTTL line driving CLK0 pull up to near 5V.

The reset pin, intially held high, is dropped to 0v. 4017Q0 shows 1
(as it should). On the next rising edge of CLK0, the '4017 advances
to Q2=1. On each subsequent rising edge, the counter advances by one,
yet on that first edge it always advances by two, from Q0 to Q2.

The clock pulses, from the LPT1: control register, show a clean
transition each time.

I'm not what you'd call new at this stuff, but this one has got me
burgered. Other than a wacky HC4017, any suggestions?

The usual culprit in this situation is of course clock bounce/ringing.
But if you checked for this right at the input pin with a scope, the
other usual culprit is too slow a transition of your input clock. In
this case caused by your O/C output, long line, and pull up resistor.
74HC devices can have a maximum rise and fall time for the inputs, if
you exceed this you can have problems. From memory it's in the order
of 500ns max at 5V, but that does vary a lot. A schmitt buffer before
your clock input should do the trick.

Dave, I appreciate the thoughts. But before posting (and exposing
myself to flak) I did a fair amount of testing and thunking.

The real brain-teaser - and the reason I think it is something "else"
- is that all subsequent clocking is normal, no glitches or bounces.

But have you actually measured the rise time of your input clock?
With an O/C output and pullup you could have a slow rising clock, that
will screw things up, even it's as smooth as a babies butt.
Please measure it for me, I need closure! :-

OK it's almost 3uS from 0v to 4v with the 10k pullup, improves to
1.8uS with a 3k3 pullup.

Now do you want to offer an explanation why this would only affect the
first clocking? That's still the bit that has me uncomfortable
rebuilding this thing with an added Schmitt.

I am single-stepping the code so there is no (timing) reason why the
first -/+ transition should be seen by the HC4017 input as anything
different from the next three or four, yet they are all one step per
-/+ transition. The only thing that IS different is the history ie.
the chip came out of reset some time (seconds) earlier.

One thing I thought of overnight but haven't implemented yet is to
come out of reset with CP0 high, then lower it. That should clear the
history cobwebs and make the first -/+ transition look more like the
second etc.

I don't think I'm a vitim of the little note on Fig 10 (p12/12) in the
Philips data sheet for the HC4017 which states:

"It is essential not to enable the counter on /CP1when CP0 is HIGH, or
on CP0 when /CP1 is LOW, as this would cause an extra count."

Yep, that's par for the course with these selectable edge inputs. Trap
for young players who don't look at the internal circuit to check
whats going on. The multiple labling of the extra clock between
manufacturers is a real pain. The 4017 ain't the only chip with this
same problem.

Fortunately, the /CP1 is bolted to 0v on my board.

PS fix the Trio eventually?

 

[budgie]

On Tue, 23 Sep 2003 18:14:26 +1000, Mike Harding
<mike_harding1@nixspamhotmail.com> wrote:

On Tue, 23 Sep 2003 07:41:05 GMT, budgie
budgie@nowhere.cantech.net.au> wrote:

On Tue, 23 Sep 2003 14:29:07 +1000, Mike Harding
mike_harding1@nixspamhotmail.com> wrote:

On Mon, 22 Sep 2003 08:54:27 GMT, budgie
budgie@nowhere.cantech.net.au> wrote:

I have a bizarre clocking situation occurring with a 74HC4017 which is
being clocked from the PC parallel port.

Conditions: CLK1 (- edge-triggered) tied to 0V. CLK0 (+ve
edge-triggered) is low. There is an additional 10k pullup to help the
O/C LSTTL line driving CLK0 pull up to near 5V.

Just one other thought:

My data sheets describe the 4017 as having 1 clock and
1 clock enable (as opposed to 2 clocks) the logic diagram
suggests there is not much difference between them though.

To my bleary eyes, the logic diagram suggests NO difference in the
function of the and gate vis--vis the two clock inputs.

One of them has an inverter and the other doesn't,
depends how you draw the internal logic as to which
one though.

That's the only difference, though. Treated as a pair of inputs, they
function the same as the pair on t'other chip.

Have you tried the push button replacement for the
clock in order to rule out/in the software?

Not yet, but I will. And I have single-stepped the software with
breakpoints everywhere so I am extremely confident it isn't software.

But I keep coming back to the fact that only the FIRST transition has
the problem. Now software COULD do that ....

 

[David L. Jones]

On Tue, 23 Sep 2003 12:14:00 GMT, budgie
<budgie@nowhere.cantech.net.au> wrote:

But have you actually measured the rise time of your input clock?
With an O/C output and pullup you could have a slow rising clock, that
will screw things up, even it's as smooth as a babies butt.
Please measure it for me, I need closure! :-

OK it's almost 3uS from 0v to 4v with the 10k pullup, improves to
1.8uS with a 3k3 pullup.

Ok, I think you'll find that's way outside of the spec.

Now do you want to offer an explanation why this would only affect the
first clocking? That's still the bit that has me uncomfortable
rebuilding this thing with an added Schmitt.

No idea, your guess is as good as mine. Would love to know exactly
what the mechanism is though... Anyone?
But I have seen wierd problems like that caused by slow inputs into
logic gates.
Seeing as that you've tried and checked everything else, an out of
spec input rise time stands out like a sore thumb as the obvious
culprit.
Can't you cut a track or two and temporarily insert a schmitt buffer?
Baring that, try going really low in value (a few hundred ohms maybe)
on your pull-up and/or shortening your parrallel port cable to lower
your capacitance. If you can get the rise time down to a few hundred
ns, you might be on a winner.

Fortunately, the /CP1 is bolted to 0v on my board.

PS fix the Trio eventually?

Not yet. Moving house soon too, and I've been told to ditch those old
"oscilloscope thingys" - I ain't giving up without a fight!
Got a nice Tek 466 that needs work too.

Regards
Dave
---------------------------
(remove the "_" from my email address to reply)

 

[David L. Jones]

On Tue, 23 Sep 2003 13:02:30 GMT, tronnort_@yahoo.com (David L. Jones)
wrote:

On Tue, 23 Sep 2003 12:14:00 GMT, budgie
budgie@nowhere.cantech.net.au> wrote:
But have you actually measured the rise time of your input clock?
With an O/C output and pullup you could have a slow rising clock, that
will screw things up, even it's as smooth as a babies butt.
Please measure it for me, I need closure! :-

OK it's almost 3uS from 0v to 4v with the 10k pullup, improves to
1.8uS with a 3k3 pullup.

Ok, I think you'll find that's way outside of the spec.

Now do you want to offer an explanation why this would only affect the
first clocking? That's still the bit that has me uncomfortable
rebuilding this thing with an added Schmitt.

No idea, your guess is as good as mine. Would love to know exactly
what the mechanism is though... Anyone?
But I have seen wierd problems like that caused by slow inputs into
logic gates.
Seeing as that you've tried and checked everything else, an out of
spec input rise time stands out like a sore thumb as the obvious
culprit.
Can't you cut a track or two and temporarily insert a schmitt buffer?
Baring that, try going really low in value (a few hundred ohms maybe)
on your pull-up and/or shortening your parrallel port cable to lower
your capacitance. If you can get the rise time down to a few hundred
ns, you might be on a winner.

Here is the Fairchild/Nat Semi App Note on this.
http://www.fairchildsemi.com/an/AN/AN-317.pdf

There is a section on Input Rise and Fall times.

Regards
Dave
---------------------------
(remove the "_" from my email address to reply)

 

[budgie]

On Tue, 23 Sep 2003 13:02:30 GMT, tronnort_@yahoo.com (David L. Jones)
wrote:

On Tue, 23 Sep 2003 12:14:00 GMT, budgie
budgie@nowhere.cantech.net.au> wrote:
But have you actually measured the rise time of your input clock?
With an O/C output and pullup you could have a slow rising clock, that
will screw things up, even it's as smooth as a babies butt.
Please measure it for me, I need closure! :-

OK it's almost 3uS from 0v to 4v with the 10k pullup, improves to
1.8uS with a 3k3 pullup.

Ok, I think you'll find that's way outside of the spec.

Yes, the spec is 500uS as I think you said.

Now do you want to offer an explanation why this would only affect the
first clocking? That's still the bit that has me uncomfortable
rebuilding this thing with an added Schmitt.

No idea, your guess is as good as mine. Would love to know exactly
what the mechanism is though... Anyone?
But I have seen wierd problems like that caused by slow inputs into
logic gates.
Seeing as that you've tried and checked everything else, an out of
spec input rise time stands out like a sore thumb as the obvious
culprit.

That's next on the list. The problem originated by me overlooking the
fact that the control port outputs were o/c, and treating them like
the data port. Betcha I don't do that a second time.

Can't you cut a track or two and temporarily insert a schmitt buffer?
Baring that, try going really low in value (a few hundred ohms maybe)
on your pull-up and/or shortening your parrallel port cable to lower
your capacitance. If you can get the rise time down to a few hundred
ns, you might be on a winner.

Actually, the drive to the 4017 also goes to an HC04. I'll pull that
and use an HC14, and put the spare sixth inverter after the one
already off the clock line, so retaining the current phasing and
sharpening it up in the process. Bit of track butchery, but that's
what protos are all about.

PS fix the Trio eventually?

Not yet. Moving house soon too, and I've been told to ditch those old
"oscilloscope thingys" - I ain't giving up without a fight!
Got a nice Tek 466 that needs work too.

Has SWMBO tried the old "either it goes or I do" line? If she
has/does, ask if you can have time to consider your response ;-)

 

[Mike Harding]

On Tue, 23 Sep 2003 12:14:04 GMT, budgie
<budgie@nowhere.cantech.net.au> wrote:

Have you tried the push button replacement for the
clock in order to rule out/in the software?

Not yet, but I will. And I have single-stepped the software with
breakpoints everywhere so I am extremely confident it isn't software.

I always am too - every time

Mike Harding

 

[budgie]

On Tue, 23 Sep 2003 03:12:14 GMT, budgie
<budgie@nowhere.cantech.net.au> wrote:

(snip)

I have a bizarre clocking situation occurring with a 74HC4017 which is
being clocked from the PC parallel port.

(snip)

The thing that has got me .. er, puzzled, is that (as posted in
responses elsewhere) it is ONLY the first lo-hi transition after
reset release that causes the double-clocking effect. And as I am
still at the stage of single-stepping the software, the reset is gone
some seconds before the first lo-hi CP0 transition.

On Tue, 23 Sep 2003 12:20:34 +1000, Mike Harding
<mike_harding1@nixspamhotmail.com> wrote:

Keep us informed of your progress please.

Will do, even it is totally embarassing.

<red face>
OK, the cause was definitely too slow a clock rise time.
</red face>

But the weird bit is why it ONLY double-clocked from the "0" state
after reset was removed, and not on subsequent clocks. That still
hasn't found an explanation.

Sincere thanks to all who took the time to offer suggestions.

 

[Mike Harding]

On Fri, 26 Sep 2003 04:45:55 GMT, budgie
<budgie@nowhere.cantech.net.au> wrote:

red face
Nah. If it was easy everyone would do this sort of thing.

OK, the cause was definitely too slow a clock rise time.
/red face

But the weird bit is why it ONLY double-clocked from the "0" state
after reset was removed, and not on subsequent clocks. That still
hasn't found an explanation.

My guess is simply that the internal logic is in a unique
state after reset is released.

We should have a thread called "My best stuff-ups"
I could probably fill it on my own; like the time my brilliant
reverse polarity protection didn't

Mike Harding