TCA9546A on PCAM Add On Board

[BMC99]

Trying to enable each of the 4 output channels on the TCA9546A.

Sheet 14 appears to be the relevant section of the datasheet: https://www.ti.com/general/docs/suppproductinfo.tsp?distId=10&gotoUrl=https%3A%2F%2Fwww.ti.com%2Flit%2Fgpn%2Ftca9546a

My A2, A1 and A0 pins are all tied low in hardware.

Refer to the attached scope shot. Blue is data yellow is clock.

After the initial write, I write 11100000, which should corespond to the fixed slave address and the state of those 3 pins.

Then I write 00001111. The first 4 bits are don't cares and the 4 ones should enable all 4 channel outputs.

However, I still can't get anything out of any channel with any subsequent writes.

Is there another subsequent or prior write I have to do? What could I be missing?

[thinkthinkthink]

I only see you writing 11000000 (0xC0) for addressing the TCA9546A i2c slave when you should be writing 11100000 (0xE0).

[BMC99]

Sorry but why do you think that?

The data line is high for 3 consecutive rising edges from time about 120 us to 140 us, then low for 5 consecutive rising edges.

 

[thinkthinkthink]

My bad, I was looking at the bits after the start/repeated start condition.

Also are you using an AXI IIC IP or the PS_IIC inside the zynq to communicate over i2c with the i2c mux on the fmc pcam adapter ?

Edited August 10, 2022 by thinkthinkthink

[BMC99]

Was pulled away from this task for a few days.

I'm using the P2 IIC.

Actually using the xilinx ZC702 board with the digilent FMC adaptor. That means the i2c traffic goes from the PS I2C port through an I2C mux PCA9548ARGER on the xilinx board to the FMC I2C port. The scope shot that I posted was taken right at the pins of the TCA9546A on the pcam adaptor, so I know the traffic is getting through that mux correctly.

[JColvin]

Hello,

Just wanted to let you know that thinkthinkthink has also been pulled away from this task for a little while (verification tests of hardware prototypes), but did let me know that they do have some additional feedback regarding this but want to test it out on hardware first before providing potentially faulty information.

Thanks,
JColvin

[thinkthinkthink]

Hi @BMC99

This is how the I2C transactions should look like if you have a system board with an I2C MUX on it (i.e. TCA9548) while wanting to communicate with a Pcam that's also behind another I2C MUX (i.e. TCA9546):

First I'm writing a (1 << 4) to the TCA9548 which is at address 1110000 to open the 5th I2C channel (channel 4), then I'm writing a (1<<0) to the TCA9546 which is at address 1110001 to open its 1st channel (channel 0) and only then can I write to or read from the registers of the OV5640 which is at address 0111100. In our current published projects involving the FMC-Pcam-Adapter we don't open all channels at once. According to the TCA9546 datasheet, when a channel is selected, the channel becomes active after a stop condition has been placed on the I2C bus so make sure you do that as well.

 

[elodg]

On 8/16/2022 at 4:15 PM, BMC99 said:

Was pulled away from this task for a few days.

I'm using the P2 IIC.

Actually using the xilinx ZC702 board with the digilent FMC adaptor. That means the i2c traffic goes from the PS I2C port through an I2C mux PCA9548ARGER on the xilinx board to the FMC I2C port. The scope shot that I posted was taken right at the pins of the TCA9546A on the pcam adaptor, so I know the traffic is getting through that mux correctly.

So if the ZC702 mux is confirmed working and the I2C traffic is channeled to the FMC Pcam Adapter, the next step is addressing the mux on that, the TCA9546A.

If TCA9546A has address 1110000, why am I seeing 1010000 as slave address (first byte)? From the looks of it you are actually writing the FMC Pcam Adapter FRU EEPROM offset E0 with data 0F. It explains why the second addressing of the EEPROM is nack'd, it being busy with the internal write.