74HC125 Is not tri-stating

[lbuks]

I am trying to learn the 74HC125 in combination with the 74HC165.
I want to tristate the outputs of the 165’s so that they can share the MISO line.
But all i am getting is garbage readings.
What am i overlooking here?
(Circuit attached)

uint8_t data[2];

digitalWrite(oe_2_pin, HIGH);   //Disable register 2
digitalWrite(oe_1_pin, LOW);    //Enable register 1

digitalWrite(latch_pin, LOW);  //Latch
digitalWrite(latch_pin, HIGH);

data[0] =  SPI.transfer();     //Read register 1

digitalWrite(oe_1_pin, HIGH);    //Disable register 1
digitalWrite(oe_2_pin, LOW);    //Enable register 2

digitalWrite(latch_pin, LOW);  //Latch
digitalWrite(latch_pin, HIGH);

data[1] =  SPI.transfer();     //Read register 2

NOTES:

• I am aware that you can cascade multiple 165’s
• If i cascade the 165’s and remove the 125 my code and circuit works as expected.
• Nothing else is connected to the MISO line
• Nothing is interrupting the transfer
• SCK frequency is 11.25 MHZ (Also tested at lower and higher speeds)

[septillion]

Because you didn't post MCVE, are oe_1_pin and oe_2_pin set as output?

And do you have 74HC165 as in your text or 74LS165 as in your schematic? Last isn't 3v3 compatible. Also, I miss decoupling cap's in the circuit.

[lbuks]

septillion:
Because you didn't post MCVE, are oe_1_pin and oe_2_pin set as output?

And do you have 74HC165 as in your text or 74LS165 as in your schematic? Last isn't 3v3 compatible. Also, I miss decoupling cap's in the circuit.

Thanks for you reply.

OE pins are outputs.
All chips have 100nF decoupling caps.
Chips used are 74HC165, dont have the proper symbol, but the pinout is the same.
Using 3.3V because i am use an STM32 MCU.

[Southpark]

The first thing to do is to just get a 74HC125 on a bread-board, and then provide it with the required supply voltage ----- to power it up. And then just connect the 1OE_bar pin to a logic high voltage (which pretty much makes the output pin of buffer #1 a floating pin ----- connected to nothing). So a voltage measurement in this particular state or situation at the output pin would be sort of meaningless ------ because it's floating or tri-state. So expect random voltage measurements when doing the voltage measurement at the output pin of buffer #1 when the 1OE_bar pin is at a logic high voltage.

Now connect the 1A pin to a logic high voltage. And then use a multimeter to measure the voltage of the output pin of buffer #1. You will still expect meaningless voltages at the output, due to the de-activated buffer.

So we then connect the 1OE_bar pin to 0 volt ------ ground it. This will activate the output of the buffer #1. So the voltage measurement at the output should be a high voltage when the input 1A pin is at a high voltage.

And then connecting the 1A pin to 0 volt should make the voltage of output of buffer #1 become 0 volt as well.

Do these basic tests first - to make sure your device is working.

[dale_needham]

suspect the issue is both 74HC165 registers "Output Enable" line being low at the same time so when you try to read both are outputting into the 74HC125 and the outputs are connected so they squabble.

would explain why if you cascade the chips it works as then you want both enabled at once

I've used the 74HC165 & 74HC125 combination at 3.3v on an Arduino DUE fine, only code change was to add

delayMicroseconds(1);

between the latch toggling

try with only one register output enable tied to ground at a time (or stick both OE lines to different MCU pins and drive one active, read it then the other in turn

[dale_needham]

another point I learned (through some trial but mostly error) was that its worth tying the 74HC125 Output Enables, all of them, to something - supply or ground, or an MCU pin if desired for future expansion stuff

[lbuks]

Southpark:
Do these basic tests first - to make sure your device is working.

Thanks for helping.
I did the basic tests you described, and everything works as expected.

dale_needham:
suspect the issue is both 74HC165 registers "Output Enable" line being low at the same time so when you try to read both are outputting into the 74HC125 and the outputs are connected so they squabble.

would explain why if you cascade the chips it works as then you want both enabled at once

Shouldnt the OE lines prevent this from happening?
If only one gate is open, only one connection to MISO is made?

[septillion]

What happens is you only connect a single 165? So connect only a single 165 to the 125 A pin and only connect a single 125 Y-pin to the MCU.

[dale_needham]

lbuks:
Thanks for helping.
I did the basic tests you described, and everything works as expected.

Shouldnt the OE lines prevent this from happening?
If only one gate is open, only one connection to MISO is made?

it should yes (I mean, thats the point of the thing), however if empirically it isn't and it does work when you cascade the 165 registers it may be worth trying - I did find that you do want the other OE lines tied high/low even though not used - don't let them float.
shouldn't be issues with latching in parallel or reading in parallel the way you are then using the 125 the way you are trying to, so suspect its something in the electrical string - the 125 datasheet I found said to tie the inputs not not let them float so I did and for me it worked.
other points to note trying to make this work this end - shouldn't matter if you can read normally, but worth noting - you want the SPI clock inverted for reading a 165, I've got:

SPISettings Settings165(4000000, MSBFIRST, SPI_MODE2);

as a configuration for it, it does work at higher speeds but for me 4MHz was enough so left it there
my set up makes a point of driving the 125 OE pins high on unused channels (instead of wiring to +Vcc mine go to the MCU), with the OE lines all set as outputs. my switch read code (this is four a quartet of 165 in parallel) is then

void ReadSwitches(void)
{
  digitalWrite(Input_Load, LOW);
  delayMicroseconds(1);
  digitalWrite(Input_Load, HIGH);
  SPI.beginTransaction(Settings165);
  digitalWrite(Input_CS, LOW);
  SW0 = SPI.transfer(0);
  SW = SW0;
  SW1 = SPI.transfer(0);
  SW |= SW1 << 8;
  SW2 = SPI.transfer(0);
  SW |= SW2 << 16;
  SW3 = SPI.transfer(0);
  SW |= SW3 << 24;
  digitalWrite(Input_CS, HIGH);
  SPI.endTransaction();
}

found the initial delay helped, also found without the transaction and inverted clock it didn't work - if you have the things working as a cascade without the 165 that may not apply

[lbuks]

septillion:
What happens is you only connect a single 165? So connect only a single 165 to the 125 A pin and only connect a single 125 Y-pin to the MCU.

A little better, bud still issues.
Seems like a weird ground problem maybe.
When i move my hand close the chip i am getting random switch states.
I have checked all my jumper cables, no faulty cable.
Measured the VCC & GND rails, nothing strange there.
Any ideas what else it could be?

[septillion]

@lbuks Did you GND all unused inputs as @dale_needham suggested?

Otherwise, can you post a picture of the setup?

[lbuks]

septillion:
@lbuks Did you GND all unused inputs as @dale_needham suggested?

Otherwise, can you post a picture of the setup?

I did.
Also tried a different SPI port and GPIO speeds, no luck.
Will rebuild the whole thing from the ground up.
Testing each build stage.
Will post results.

[raschemmel]

Not sure why it isn't working , considering it appears you already tested the H/W without code and said it worked. That would seem to suggest the issue is code related. Did you mean that you simulated the code by manually connecting appropriate logic values using jumpers and it worked as expected but when you ran the code that supposedly does the same thing it did not work ?
That's puzzling.

[anon57585045]

I did.

No, that is a schematic. We're asking for images of your actual hardware.

[raschemmel]

No, that is a schematic. We're asking for images of your actual hardware.

You're asking us to troubleshoot an electronic circuit we cannot see. The photos are to help us rule out wiring issues. Obviously, if the chip was good and it was wired correctly you would probably not be posting for this
issue. ( since you said you tested the hardware without code and it was ok)

[MarkT]

1. Where did you buy your chips? Reputable?

2. How do you prevent the output enables floating LOW during power up? You need to do this
   to prevent the two outputs fighting each other. 10k pullups on both OE's would be good.

3. You took full anti-static precautions handling these CMOS logic chips? If its winter where you are
   then the air is dry and static is a definite problem you have to be careful of.

[lbuks]

aarg:
No, that is a schematic. We're asking for images of your actual hardware.

I was responding to "@lbuks Did you GND all unused inputs as @dale_needham suggested?"
Should have been more clear.
So i rebuild everything, and its working now.
First thing i found was that did have a fault cable that is missed.
Second thing is bit more strange.
Using pin PA2 as a OE pin gave me issues, the cable was not the problem.
I then changed it to PC0, still the same issues.
Finally using PB6 it did work.
I checked, double checked the code.
Using a blue pill to be clear.

Initialisation code was identical, except for the pin numbers of course.
There was nothing that was overwritting the code.
Did i blow up these pins maybe?

[Southpark]

lbuks:
Did i blow up these pins maybe?

Hard to say. But probably easy to test - by doing manual testing. If the device has 1 output, and you are able to manually wire the input(s) to the voltage levels you want, then a multimeter can be used to test the output.

[dale_needham]

lbuks:
I was responding to "@lbuks Did you GND all unused inputs as @dale_needham suggested?"
Should have been more clear.
So i rebuild everything, and its working now.
First thing i found was that did have a fault cable that is missed.
Second thing is bit more strange.
Using pin PA2 as a OE pin gave me issues, the cable was not the problem.
I then changed it to PC0, still the same issues.
Finally using PB6 it did work.
I checked, double checked the code.
Using a blue pill to be clear.

Initialisation code was identical, except for the pin numbers of course.
There was nothing that was overwritting the code.
Did i blow up these pins maybe?

if its working thumbs up, I've had some odd behaviour with a few boards of various types using some pins as inputs - occasionally the board needs a certain state on some pins or it doesn't boot or doesn't boot right (WeMos with pin D4 was infuriating), occasionally some libraries are hard coded to certain pins for certain functions too - even if you are not using that part they can take over
it may be possible the pins are damaged, it may also be that the ICs are putting out a value thats borderline for being recognised as logic 1 or logic 0, and its working better on some pins that others
another potential issue that could cause iffy readings, your switches are not de-bounced, I tried this thinking it wouldn't matter with the 165, this was incorrect - you can do it in hardware or in software but something to be aware of

[raschemmel]

Finally using PB6 it did work.

Please identify which pin NUMBERS you are using for which PIN NAMES:
FYI, if you suspect some pin may be damaged you need to perform an I/O test using an I/O test setup
INSTEAD of your current setup. As a general rule, a developer should know how to do a complete H/W
test of all MCU functions or at least a complete I/O test. One simple method I use is putting leds with
series resistors on all outputs and using digital OUTPUTS to drive digital INPUTS, typically in what is
called a "walking bit test" where you turn on one output, delay, turn it off , then turn on the next output.
The leds make it a simple visual GO/NO GO test. I have led displays with jumpers attached so all I have
to do is grab the led display and plug the wires in and it's ready to go. There is also a switch input version
of the same thing which is just push buttons or switches on a dedicated breadboard with jumpers attached
so you just grab the breadboard and plug in the wires and push the buttons and you can read the inputs
and either print the value to the serial monitor or use it to drive an output with a led connected so the led
goes on when you press the button. This is how I rule out 'bad pins' when something doesn't seem to work
right. Alternately, if you don't have the patience to build such routine test setups you can just go pin by pin
and do some kind of input or output test. I have both SPI and I2C devices I use to test those protocols. I
usually use LCDs for those since LCDs come in both flavors. (I have an 8-digit LCD ALPHANUMERIC SPI display
and an I2C 2X16 LCD display for testing SPI & I2C)

STM32 PINOUT