• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 18 subscribers
  • Views 427 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CD4059A: counter 'freezing' with quickly changing jam inputs

Ryan Sarver1
Prodigy 190 points
Part Number: CD4059A

I'm using the CD4059AM in an application where jam inputs 1 through 7 are controlled by an MCU to give different divisors. Multiple inputs can change at a time, and they should all change relatively instantaneously. For a given input, the shortest on or off time expected is around 8ms, i.e. the fastest changing input would be 8ms on, 8ms off, etc.

For the most part the circuit is working as expected, but I'm experiencing occasional bursts of the output flat-lining at GND. During this time, the input is still active, so the signal is being lost as it goes through the CD4059. From what I've seen, the bursts last anywhere from about 150ms to 600ms.

I can only imagine that changing the jam inputs so quickly is producing some kind of state that the counter doesn't like. This theory is supported by the fact that if I slow down the rate at which the inputs change, the behavior goes away. But I don't see anything in the datasheet that talks about this specific type of limitation. So I'm wondering if, first of all, it does make sense as an explanation that the inputs are changing too quickly, and secondly, if that can be a limiting factor then what's the safe region of operation? And would there be any way to improve it?

By the way, I'm almost positive it's nothing to do with the MCU program, because I also built a first iteration of this project using a parallel output ADC to control the jam inputs and I'm getting the exact same issue.

  • 0
    Prodigy 190 points

    I forgot to mention I'm operating in divide-by-10 mode

  • 0 in reply to Ryan Sarver1
    TI__Mastermind 44620 points

    Hey Ryan,

    Can you provide scope shots of the issue? Please include the output, the clock, and at least one of the jam inputs. This will help me a little to understand the issue you are having. 

  • 0 in reply to Dylan Hubbard
    Prodigy 190 points

    Hi Dylan,

    Unfortunately I only have a 2-channel scope so I can't take a screenshot of everything at once. But here's an example of the output 'dropout":

    CH2 (purple) is the output and CH1 (yellow) is the input.

    You can see that the input remains constant but the output flatlines for a bit. I just want to emphasize that this only happens with varying jam inputs; if they're constant, then I never observed the issue.

    Here's a shot of the output dropout (CH2) and jam input 4 (CH1):

    I can control the minimum pulse width of those jam input pulses with my firmware, and it seems that increasing it to 20ms gets rid of the problem. However, I'd like to be able to go lower than that.

    Other things I've noted:

    There seems to be a relationship between the input frequency and how often the output cuts out, where with lower frequencies it doesn't happen as much. For example, with 6.4kHz in, I never saw it happen. With 25.6k in, it happened sporadically. And with 128kHz in (that's about the max that I need to go), it happened pretty regularly.

    Also, the amount of time it's off is related to the input frequency, with lower frequencies being off longer.

    Thanks in advance for your help

  • 0 in reply to Ryan Sarver1
    TI__Mastermind 44620 points

    Hey Ryan,

    I see. This does seem to be involved with a set up and hold time since changing the pulse duration can fix the problem and so does having longer periods on the clock. These are typically specs included with clocked devices, but I'm not seeing them in this datasheet. There isn't a lot of info provided on dynamically changing the Jam inputs during operation so it's possible the device wasn't intended for that application which is why the timing specs involved weren't included.

    Do you know the relationship of the number of counts the output stays low with your input frequency?

    I'm assuming you are leaving the mode pins unchanged?