I2C dumping 255 as data instead of actual Values

[CK.3]

I am using about 13 (PCA9554A & PCA9554AD) I/O expander IC to connect sensors to STM32 F103 micro-controller through I2C. Upto 3 PCA9554 IC works fine, but the moment I connect 4th IC, it starts to dump 255 from all the i/O Expander ICs.

The data is latched using 74HC573 and then given to PCA9554. I presume 74HC573 works on 3.3Volts also.

The pull up resistors used in SDA & SCL is 1K. Tried using 2K2

I2C operating at 400KHz (fast mode) for faster data rate. Tried 100KHz but no change

A EEPROM IC 24C04 is used on the same I2C bus which works fine.

The same circuit and program (using HAL code) was used in two previous machine and it worked fine..

Where am I going wrong .?? Is it PCA9554 or 74HC573 related..

[TDK]

Sounds like a hardware issue. Adding another slave shouldn't affect the others already there. I2C pins are driven in open-drain mode and a high value indicates no device is pulling those pins down.

Are all slaves ACKing correctly with HAL_I2C_IsDeviceReady?

[CK.3]

HAL_I2C_Master_Transmit(&hi2c2,0x44,0, 1,1);

err = HAL_I2C_Master_Receive(&hi2c2,0x44,&data, 1,1);

if ( err != HAL_OK )

{

defect_PCB = 3;

}

else

   PU_Array3 = data;

This how each I2C slave is addressed with Error handling but no defect PCB shows up in the LAN string

[Andrew Neil]

"Upto 3 PCA9554 IC works fine, but the moment I connect 4th IC, it starts to dump 255"

So how many address options does the PCA9554 have ?

EDIT

should be 8:

 

so have you set distinct addresses on all the attached slaves?

[Andrew Neil]

"I presume 74HC573 works on 3.3Volts also"

Don't presume - confirm with the datasheet.

"Is it PCA9554 or 74HC573 related"

What testing / investigation / debugging have you done to find out?

eg, remove the latches and just supply fixed inputs to the expanders - does that work?

Do you have a logic analyser and/or oscilloscope to see what's actually happening on the wires?

Have you used the debugger to see what's actually happening in the code?

"The same circuit and program (using HAL code) was used in two previous machine and it worked fine"

Beware the "Proven Product Syndrome" - it's not uncommon for flawed systems to appear to "work" until you do something that tips them over the edge...

https://www.avrfreaks.net/comment/3142921#comment-3142921

https://www.avrfreaks.net/comment/2352741#comment-2352741

[TDK]

Again:

Are all slaves ACKing correctly with HAL_I2C_IsDeviceReady? That is always step 1 to debugging I2C problems.

[CK.3]

Tried out all as suggested by TDK & Neil. The problem was finally solved. Checked 3.3Volts on the nearest I2C board and the far away board to be 2.98V. Did not take it seriously. After having tried out all possibility, ran two wires (3.3V and ground) from supply source to the last I2C board. Every thing started to work fine.

Thanks for the support

But why it didn't happen to the previous two machines ???

[Andrew Neil]

​ "But why it didn't happen to the previous two machines ?"

Again, "Proven Product Syndrome" ...

"The problem was finally solved"

Jolly good - now please mark the solution: