Post Go back to editing

Cannot switch S1/D1 off on ADG1414

Hi, I have made a very simplistic setup with an arduino and the ADG1414.

And the program has a counter going from 0 to 255 and it writes this counter out via the SPI.

All switches are working just fine except S1/D1 all the other follow the count sequence just fine.

I've double and tripple checked toe connections and they are just fine. I've switched between several ADG1414's no luck.

I've of course set the speed so I would see it and I've also used a logic analyzer with same result :-(

Any ideas out there?

Here is the schematic

Thanks in advance

Error in schematic :-)
[edited by: JarlAtCloud at 7:21 PM (GMT -5) on 26 Nov 2020]
  • Hi,

    If you have already checked several ADG1414 devices I would rule out the ADG1414 as being the cause of the issue.

    Can you share the output of the logic analyzer?

    Have you checked that all the LEDs are actually working (apologies for stating the obvious but i would like to rule that out)



  • Sure here it is. Also weird is those dips that channel 1 has. And yes the LED's are ok :-)

    I only mounted the LED's because I started measuring the problem, so the problem is there without any load.

    I'm using channel 1 as clock as you can see and there is a dip on all channels it's not a reset, since reset is tied to VCC.

    It is not a load since all pins are connected to the logic analyzer only.

    Above is the output from the logic analyzer

  • Actually looking into some of these dips are disturbing. Does not seem likely that this chip can be used:-( 

    I use the ADG1412 just fine but I wanted to avoid using too many connections on my controller and did not want to extend the BOM with an extra port expander, but if these dips are expected result of the shift register being filled etc. then it is not usable for my usage.

    The circuit is SO simplistic and basic so I simply cannot see where the error could be except in the chips them selves, but I've tried a few some of them from a completely different batch.

  • I would not say that we could rule out the ADG1414 as such, since this is the chip producing the issue :-) 
    But we could assume that the communcation to it has something to do with it.

    Could it be some sort of timing issue between the ATMega I2S and the ADG1414? Or something like that maybe?