cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
12,617 Views
Registered: ‎01-12-2014

I2C Bus Switch (PCA9548A) cannot be configured

Hello,

 

I am writing because of a problem we are experiencing programming the I2C Bus Switch on out VC707.

We are working with XPS and EDK, my colleague is taking care about the generation of the firmware, while I am programming the C software application to drive it.

 

My colleague has added an I2C Master device inside the design, so what I would like to do now is switching the output signals of the I2C to our FMC device on the HPC1, where we have a slave I2C interface allowing us to communicate with several devices.

 

I am using the low level functions XIic_Send and XIic_Recv in order to programm the devices, so also the switch.

From the datasheet of the PCA9548A I saw that in order to activate the desired channel is enough to write 0b00000010 into the control register of the switch, so I programm it by addressing the master (through its base address 0b40800000) to write on the bus switch (0x74) the value 0x02:

 

XIic_Send(I2C_BASE_ADDR, 0x74, 0x02, 1, XST_STOP);

 

Here is already the problem because the function is terminating without success, so this could mean several things, such as that the device at the address 0x74 is not correctly answering or that the design is not instantiating the I2C correctly.

 

As an additive information I can say that the I2C was already integrated inside the basic design available just by opening XSP, where a whole microblaze system is already done (DDR3, Ethernet, GPIO....etc. etc.).

 

Reading the manual of the VC707, from my understanding, seems like the switch is anyway placed between the I2C Master on the FPGA and the slave devices. Ist this correct? Or or should be instantiated something from the point of view of the system built up with XPS?

 

Our I2C is configured to work with 7-bits addresses and non dynamic mode.

 

In case we are doing everything correctly on XPS, which could be the reasons why the function should end up wrong? I think I am calling it correctly, this is what I have also read on another topic on this forum.

 

Any tips?

 

Best Regards,

 Giovanni

Tags (4)
0 Kudos
15 Replies
Highlighted
Xilinx Employee
Xilinx Employee
12,535 Views
Registered: ‎01-03-2008

The address (0x74) for the PCA9548A switch is correct and the data (0x02) is correct for enabling the path to the HPC1 FMC interface.   

 

Did you assign the SDA to pin AU32 and SCL to AT35?   Have you placed a scope probe on these lines either at the U52.20 (SDA) and U52.19 (SCL) or R61 (SDA) and R60 (SCL) to verify that signals are reaching the device?

------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
0 Kudos
Highlighted
Observer
Observer
12,515 Views
Registered: ‎01-12-2014

Hello,

 

the assignments are looking ok:

 

NET IIC_MAIN_SCL LOC = "AT35"  |  DRIVE = "8"  |  IOSTANDARD = "LVCMOS18"  |  SLEW = "SLOW";
NET IIC_MAIN_SDA LOC = "AU32"  |  DRIVE = "8"  |  IOSTANDARD = "LVCMOS18"  |  SLEW = "SLOW";

 

they should be correct. We will try now to set probes at the position which you have suggested to me. And I will come back to you with the result of this test.

 

BR,

 Giovanni

0 Kudos
Highlighted
Observer
Observer
12,494 Views
Registered: ‎01-12-2014

Hello,

 

we have measured the signals at R60 and R61.

 

I have tried configuring the I2C Bus switch with by the command:

 

u8 data = 0x02;

XIic_Send(I2C_BASE_ADDR, 0x74, &data, 1, XIIC_STOP);

 

On the two lines we see just the first part of the I2C communication where 0x74 is sent to the slave (I2C Bus), but after that we should see also the data (0x02) travelling. On what could this depend?

 

We have already run other reference designs which are working and are not so different from our, like the BIST design, where the I2C bust is configured to communicate with the EEPROM, but with our design we are appearently not able to do the same.

 

Could this depend on some wrong configuration inside the XPS project? We have instantiated an I2C Master but there is nothing related to the switch.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
12,490 Views
Registered: ‎01-03-2008

Since other designs on the board work correctly that rules out a hardware issue.  It sounds like the PCA9548 did not return an ACK.   Does this match what you observed with the scope?  Can you post the scope trace of the transaction?

 

One remote possibility is that you are not using an IOBUF on the SCL and SDA lines and are actively driving the interface at all times so that the ACK cannot happen.  Please confirm that the Pinout Report shows these as BIDIR in the direction column.

------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
0 Kudos
Highlighted
Observer
Observer
12,481 Views
Registered: ‎01-12-2014

Hello,

 

I am posting here a picture of our scope trace. Basically when I call the XIic_Send() function, on the I2C Bus I see that the address (0x74) is sent with a send request, after this the bus returns to the initial state and no ACK is received, and also the 0x02 configuration is sent to the I2C Bus Switch.

 

The constraints should be right (MHS):


 PORT IIC_MAIN_SDA = IIC_MAIN_SDA, DIR = IO
 PORT IIC_MAIN_SCL = IIC_MAIN_SCL, DIR = IO
 PORT IIC_MUX_RESET_B = IIC_MUX_RESET_B, DIR = O

 

We have had a look into one of the working reference designs from the producer of the board we are trying to drive, and we have figured out that also there, their I2C Maste block, has IOBUFS on SDA and SCL. How could we set up this on XPS? Basically we have thought that instantiating the I2C Master and connecting it to the AXI Bus, everything would be ready to use and programm.

 

 

 

tek00001.png

0 Kudos
Highlighted
Historian
Historian
12,476 Views
Registered: ‎02-25-2008


@8strings wrote:

Hello,

 

I am posting here a picture of our scope trace.


Your pullups look awfully weak. For 3.3V rails, the usual pullup resistors are 2.2k.

 

 

----------------------------Yes, I do this for a living.
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
12,472 Views
Registered: ‎01-03-2008

If the scope shot is from your design it should be using the IOBUF as there is a very slow rise time indicating that IO was tristated and controlled by the pullup on the board.

 

Looking at the waveforms it appears that the SCL period is 4uS or 250 KHz.  This is too fast and needs to be slowed down to 100 KHz to give the pullup enough time to register.  This may be the problem or your design may also be asserting the mux reset line.

------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
0 Kudos
Highlighted
Observer
Observer
12,457 Views
Registered: ‎01-12-2014

Hi bassman59,

 

actually the rails at that point are not 3.3 V. I have checked the schematics of the VC707 and those pull-up resistors are connected to 2.5V (Vcc25).

0 Kudos
Highlighted
Observer
Observer
12,456 Views
Registered: ‎01-12-2014

Actually, we have tried to let the rails run up to 400KHz. We will try to set it back to 100 KHz and run the measurement again.

 

 

0 Kudos
Highlighted
Historian
Historian
7,592 Views
Registered: ‎02-25-2008


@8strings wrote:

Hi bassman59,

 

actually the rails at that point are not 3.3 V. I have checked the schematics of the VC707 and those pull-up resistors are connected to 2.5V (Vcc25).


What is the value of your pullup? Are you relying on the FPGA's internal pullups? If so, don't; they're too week. For 2.5V rail you might need something as strong as 1k.

----------------------------Yes, I do this for a living.
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
7,591 Views
Registered: ‎01-03-2008

The VC707 board value is 4.7K.  In hindsight these should probably have been stronger this would not be a factor based on the voltage, but on the overall capacitance and desired rise timed.

 

The OP has already stated the I2C interface works fine with other designs and I think that it is just being run too fast. Dropping it below 100 KHz should resolve the problem.

------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
0 Kudos
Highlighted
Observer
Observer
7,321 Views
Registered: ‎01-12-2014

Hello,

 

we have tried running the I2C with 100 KHz, and lately also with 90 KHz, but it still didn´t work.

We will try to slow it down more, but I have heard from some of my colleagues that their designs (developd just with an older version of the SDK 14.4 or also 13) were working correctly.

 

We are going to try a rollback of our design suite and try this again. I will come back with more updates.

 

 

0 Kudos
Highlighted
Observer
Observer
7,116 Views
Registered: ‎01-12-2014

Hello,

 

I am passing by to say that actually I was able to manage the problem myself.

 

The problem was not related to wrong programming of the i2c bus switch, but to the address of the slave device which I was trying to call afterwards. Actually what I was wrongly guessing was the the I2c bus switch would stay between the i2c master on my VC707 and he devices behind it, as if it was directly the i2c device to address for the requests.

I have pointed out just afterwards that this device was going to be completely transparente and that I could already address the nex device on my daughter card.

 

A second problem was related to the low level functions wich I wanted to use. Measuring the I2C bus, I have seen that the address and the data were sent consequently....without the address of the targert register on the bus. After passing to the high level functions and initializing the i2c correctly, the problem was solved.

 

Thanks everybody for your suggestions!

Highlighted
Anonymous
Not applicable
5,269 Views

I'm also facing the same issue with PCA9548 switch, when i try to connect with USER CLK slave. Did you find any solution to fix this issue, if so please share, it would be very helpful.

 

Thank you,

Renga

0 Kudos
Highlighted
Anonymous
Not applicable
5,264 Views

I have configured the switch to access USER CLK slave, and when i address the USER CLK it is not acknowledging. 

0 Kudos