SCL in I2C stuck low in PCA9554 when more than 2 are connedcted.

Go To Last Post
36 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have to connect 12 in Nos  PCA9554 to read data on its input i/o at 400KHz SCL frequency. all is well till 2 PCA9554 are connected. The moment a 3rd slave I2C ic is connected, SCL is stuck at low from +5V. I have used a pull up resistor of 10K. Is it too high or too low. PCA9554 data sheet shows a 10K in its drawing, but for one IC. Reduced SCL to 320 KHz but no use. SCL stuck low and micro-controller hangs.

 

I load Command 0x00 (read command) on start up to all PCA9554 individually. Later when data is to be retrieved, START with Address+read  followed be NAK to individual PCA9554 and finally a STOP.

 

OK till 2 ICs, but on 3rd, the controller hangs with SCL stuck at low.

 

The whole exercise was done successfully  with 12 nos PCF8574 but data retrieval rate was not sufficient.

 

Solution please. Awaiting.

 

K.Chandramohan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

K.Chandramohan wrote:
Solution please. Awaiting.

Not the term I would use unless you are looking for snippy answers.

 

Draw your schematic of your set up AND post your code for controlling the devices.  All the crystal balls were taken back after the merger.

 

DO you have two units addressed the same by chance?  Did you try using a different IC in the batch as you might have a bad one?

 

JIm

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

Last Edited: Wed. May 3, 2017 - 12:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since I need 12 of them, I used PCA9554( address 40 plus A0,A1,A2) and PCA9554A ( address 70 plus A0,A1,A2). Its only when I include a 3rd IC it hangs( 0f course coding catering for the 3rd IC now). I did try with another set of the same IC. Same problem, after 2 IC it hangs. So coding may not be the problem ( I presume). May be pull up resistor value to be dropped?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
Draw your schematic of your set up AND post your code for controlling the devices.  

When Jim said, "Draw your schematic" - he, of course, meant for you to post that drawing!

 

How to post images: http://www.avrfreaks.net/wiki/em...

 

How to post code: http://www.avrfreaks.net/comment...

 

EDIT

 

Full, step-by-step, instructions on how to take a screenshot and how to get it into a post:

 

http://www.avrfreaks.net/comment...

 

 

#PostImageAndCode

 

Last Edited: Fri. Sep 1, 2017 - 09:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you examined the signals on an oscilloscope?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
void i2c_start(void)
{
	TWCR = (1<<TWINT) | (1<<TWSTA) | (1<<TWEN);		
	while(!(TWCR & (1<<TWINT)));
}

void i2c_write(void)
{ 
	TWDR = write_data;								
	TWCR = (1<< TWINT)|(1<< TWEN);
	while(!(TWCR & (1<<TWINT)));
}

void i2c_readNak(void)						 	
{
	TWCR = (1<<TWINT) | (1<<TWEN);
	while(!(TWCR & (1<<TWINT)));
	read_data = TWDR;	
}	

void i2c_stop(void)
{	
	TWCR = (1<< TWINT)|(1<< TWEN)|(1<<TWSTO);
	while(TWCR & (1<<TWSTO));						
}

void get_data(void)
{
    i2c_start();							
	write_data = 0x71;				
	i2c_write();	
	i2c_readNak();
	PU_Array1_up = read_data;	
	
	delay(20);						// delay added for restart condition		
	i2c_start();							
	write_data = 0x73;		//PCA9554 address:71 73 75 77 79 7B 41 43 45 47 49 4B
	i2c_write();
	i2c_readNak();
	PU_Array2_up = read_data;
		
	delay(20);	
	i2c_start();							
	write_data = 0x75;					
	i2c_write();
	i2c_readNak();
	PU_Array3_up = read_data;			
		  
    i2c_stop();
    
}

Till 2 ics, fine. On 3rd IC, SCL stuck low and controller hangs. On start up The ICs are loaded with Read command(0x00). SCL freq = 320K

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are the address lines, A0-A2, wired correctly on all the chips?

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

K.Chandramohan wrote:

Since I need 12 of them, I used PCA9554( address 40 plus A0,A1,A2) and PCA9554A ( address 70 plus A0,A1,A2). Its only when I include a 3rd IC it hangs( 0f course coding catering for the 3rd IC now). I did try with another set of the same IC. Same problem, after 2 IC it hangs. So coding may not be the problem ( I presume). May be pull up resistor value to be dropped?

12 Slaves @  20pF input capacitance is 240pF.   400kHz bus (2.5us) would need a risetime of < 0.5us i.e 2k pullups.   10k is far too high unless you have low capacitance wiring.

 

Regarding your "code".   You have been a Forum member for over 10 years.   Why would you use void functions?

 

Personally,  I would never bother with a scope.   If you have a scope,  you can view the risetime for yourself.

 

Seriously,   a single 100 pin MCU would probably be far easier than 12 I2C chips.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

Seriously,   a single 100 pin MCU would probably be far easier than 12 I2C chips.

 

Just an aside:  These are 8-signal I/O chips.  12 of them is 96 I/O pins.  There aren't any 8-bit AVRs with 96 I/Os.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:
There aren't any 8-bit AVRs with 96 I/Os.  

But there are plenty of MCUs with 100 - and more - IOs !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
Draw your schematic of your set up AND post your code for controlling the devices.  

 

awneil wrote:
When Jim said, "Draw your schematic" - he, of course, meant for you to post that drawing!

 

And still no sign of a schematic!

 

david.prentice wrote:
10k is far too high unless you have low capacitance wiring

Are you testing on a "solderless breadboard"?

 

A "solderless breadboard" will not have low capacitance wiring !!

 

surprise

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

Scroungre wrote:
There aren't any 8-bit AVRs with 96 I/Os.  

But there are plenty of MCUs with 100 - and more - IOs !

 

For all we know, the OP already has one, and needs 96 MORE.  I calculated awhile back that if you used port expanders to drive the chip selects of port expander chains you could have something like 250,000 (yes, a quarter-million) I/Os on an ATtiny2313.  To be fair, I don't have any application in mind for that, but you can if you want to.

 

More usefully, I think I agree with:

david.prentice wrote:
10k is far too high unless you have low capacitance wiring

 

Try 1k.  No, the built-in AVR pullups will NOT do.

 

S.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, the I2C ics have been addressed correctly. The pull up resistor had been brought down to 2K2 from 10K and checked. in fact SCL freq was brought down to 100KHz from 320KHz but didnt help. As of now only 3  PCA9554 ICs connected. A DS1307 on the same bus  was removed physically and software for the same was disabled but didnt help. Each board VCC  hac decoupling capacitor for each  individual IC (one PCA9554 and two  74HCT573, one LM358) of 0.1 mfd 50V disc, in addition to  10mfd electrolyte (was previously 2.2mfd 63V). The VCC of 5V is rock steady at 5.96V without any spikes, depression, no noise (on oscilloscope). The built in pull ups of PortC-0 & 1 (ATMega32) have been switched off.

    The same circuit worked fine with 12  PCF8574 which has been now replaced with PCA9554.

 

The DS1307 works at SCL freq=100 KHz (TWBR = 0x48) and PCA9554 at SCL freq = 320KHZ (TWBR=0x11) uptill two ICs only. On third, SCL stuck low. As mentioned above, DS1307 removal has not helped.

 

Sorry for not posting the drawing. Shall post, have to take some time drawing it.

 

Thanking you.

K.Chandramohan

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

5.96V means that your AVR will not last too long. I think that 5.5V is the upper limit for VCC
.
PCF8574, PCF9554, DS1307 should all work fine. Use a common 100kHz bus for i2c_start. Once a faster Slave has been addressed, you can run the bus at 320kHz.
.
Schematics and photos would be helpful. But most importantly, use non-void functions and see which error status appears where.
.
Using a proven library would inspire confidence.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
5.96V means that your AVR will not last too long. I think that 5.5V is the upper limit for VCC

 

That was about my reaction, too.  Five Point Nine Six!  Yikes! 

 

I hope that was a typo for 4.96.

 

Yes, 5.5v is the maximum, and no, your AVR won't last long at that rate.  I once had a "5V" supply that was actually putting out about 5.8 and went through a half-dozen ATmega32u4s (yes, smoking a 44-pin SMT chip off the board each time) before finally finding just why they would work fine for a few minutes, then silently quit.

 

S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

K.Chandramohan wrote:
Sorry for not posting the drawing. Shall post, have to take some time drawing it.

surprise

Seriously?! You're working on a design with at least 13 chips - and you don't have a schematic?!

 

A scope plot of what's actually happening on the I2C lines would really help

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 Sorry, 4.96V and not 5.96V

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"use non-void functions and see which error status appears where."

 

Please post a sample, will be of help to me

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
"use non-void functions and see which error status appears where."

K.Chandramohan wrote:
Please post a sample, will be of help to me

 

int8_t do_something()
{
    
   :
   // it worked
   return 0;          // 0 indicates success

   :
   // it failed
   return error_code; // use negative numbers for errors
}

 

Then, when you use it:

   result = do_something();

   if( result < 0 )
   {
      // It failed - handle the error...
      :
   }
   else
   {
      // It worked - continue...
      :
   }

 

Use an enum or #defines to give your error codes meaningful names.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

In case anyone cares, here's the spec sheet for the driver chip involved. 

 

http://www.nxp.com/documents/data_sheet/PCA9554_9554A.pdf

 

I note they're all SMT.  Unless you've installed and removed more than a few already (possibly, given how exasperated you sound) I'd take a long hard look (with magnification) at some of those solder joints.  A tiny hair of solder can cause all manner of grievances.

 

S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Changed The ICs from PCA9554A to PCA9554 and accordingly changed address form  0x70 to 0x40 and worked well. Six 6 IC (Address 0x40,0x42, 0x44, 0x46, 0x48 & 0x4A) all responded to data retrival. But I need 12 Ics. Added 2 of PCA9554A with Address of 0x70 and 0x72. All 8 ICs responded. Added one more of PCA9554A with address 0x74, the controller hung.

 

Is it a problem with the batch of these ICs or PCA9554A is a problem IC ?. No special instructions on addressing in the Data sheet

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you ruled out software defects?
If it is bus loading, then decreasing the bus pullup resistors should make a difference.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You still haven't posted your schematic!!

 

Also post oscilloscope screenshots of working and non-working cases.

 

K.Chandramohan wrote:
the controller hung.

So where, exactly, does it hang?

 

is it a problem with the batch of these ICs or PCA9554A

far more likely to be a problem in your software.

 

http://www.catb.org/~esr/faqs/sm... - applies also to chips

 

Do these chips all work individually?

 

Again, look at scope traces for the "good" and "suspect" ones - is there any obvious difference?

 

Look at scope traces for a single chip, then 2 chips, then 3, etc - do you see any progressive degradation as you add more chips?

 

 

Last Edited: Thu. May 11, 2017 - 08:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Have you ruled out software defects?

A key suspect when stuff "works" in a simple case (just a few slaves) but "fails" in a more complex case (many slaves) is that something in your code is marginal.

 

In other words, in the "simple" case, it is only just working - or "barely" working; or working by pure luck -  so that, in the "bigger" case, your luck runs out.

 

And a key suspect for the marginality would be timing - again, the oscilloscope should show this.

 

Last Edited: Thu. May 11, 2017 - 08:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It would be helpful to show a photo of your actual setup.

 

I2C is really designed for multiple chips on a single pcb.   If you have long external bus cables to remote Slaves there will be difficulties.

 

I would expect 12 PCA9554 chips on a conventional double-sided pcb would not have a high capacitance.   My rough calculation in #8 was very pessimistic.    Good conventional pcb layout would be nearer  15pF per chip.  

 

Stronger bus pullups and lower bus speed will help.    Bad layout can ruin anything.

 

Seriously,   use a proven library.   Always test the return values from the non-void library functions.    See where the problems arise.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
It would be helpful to show a photo of your actual setup.

+99!

If you have long strings of solderless breadboards, that has a huge potential for problems!

 

Not just problems on the I2C lines;  also power supply & ground - have you checked them on your scope?

 

When you say

OK till 2 ICs, but on 3rd, the controller hangs

is that always with the 1st IC in the position closest to the MCU, then the 2nd in the 2nd position, the 3rd in the 3rd position, etc?

If so, what happens if you start by putting the 1st IC in the furthest position?

 

I wrote:
something in your code is marginal.

Just to be clear, that means:

  • either, something in your code is barely within spec;
  • or, something in your code is just out-of-spec.

 

Other random thoughts:

 

  • You do only have one set of pullups for the bus, don't you?
    ie, not one set of pullups per slave?!
     
  • Are you purely testing comms to the slaves, or is there anything actually connected to the slave's outputs?
    ie, could it be the switching of the loads the causes the problem ... ?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PCA9554 and PCA9554A are ditto except the address. How come six PCA9554 with two PCA9554A added work while the 3rd PCA9554A creates the problem, Its the same code. When only PCA9554A are used, the 3rd IC creates the problem. Individually they work. Pull up resistor is now down to 2K2. Wave shape of SCL and SDA show flat tops and bottoms. (Unable to photo as trigger not locking, being 25 years old Analogue CRO, time for a new DSO). VCC and ground checked with CRO, all fine.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please go back through the recent posts and ensure that you answer all the questions - you have missed a huge number!!

 

Wave shape of SCL and SDA show flat tops and bottoms

Well that's a start, but there's a whole lot more to it than that!!

 

You need to verify timings & levels!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hc595 would have been cheaper methinks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

<aside>

Why do you need a latch anyhow - surely, the PCA9554 does that anyhow?

 

Or, just use shift registers?

</aside>

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please post a photo of your hardware.

 

What are you trying to do?

If you are simply monitoring "input switches",   life would be simpler with a multi-legged AVR or two.

If you are using the Bus Expanders as "outputs",   an MCU may not be able to drive all its pins with many milliAmps.

 

If you have sensible layout,  your schematic looks fine to me.

 

David.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On Thu. May 11, 2017 - 09:31 AM, david.prentice wrote:
It would be helpful to show a photo of your actual setup

On Thu. May 11, 2017 - 12:41 PM, david.prentice again wrote:
Please post a photo of your hardware.

 

Come on, K.Chandramohan  - don't make us keep repeating the same questions!

 

See #28

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

make SCL output. PC0 in ATmega32. and yes 74HC595 will be way better if u using it just for output.

 

In old days i used 24C512 and DS1307 at 400khz, the AVR detects both individualy but when i put both together it was not detecting anything and > start condition OK >  sending Address ERROR. every time.

i tried changing pullups I2C speed and replaced chip. nothing got solved. 

 

Finally the problem was a button cell of RTC. i was trying all efforts without cell on board. after adding cell everything was perfect. Since then I'm using DS3231.

Trust is expensive u can never expect it from cheap ICs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Pull up resistors MUST be at the END of your communications bus, NOT at the AVR for proper operation. Especially with 12+ devices on the bus.  THis could be why your comms fail after a certain point. 

 

<aside>

Why do you need a latch anyhow - surely, the PCA9554 does that anyhow?

Agreed.  the 9554 can latch it's outputs, but I do not think it can latch inputs.  Methinks the OP is 'sampling' inputs with the 573 and then shifting them out with the 9554.  I have not read the datasheet on the 9554 in detail so I may be wrong on teh input part.

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pratik Suthar wrote:

make SCL output. PC0 in ATmega32. and yes 74HC595 will be way better if u using it just for output.

 

In old days i used 24C512 and DS1307 at 400khz, the AVR detects both individualy but when i put both together it was not detecting anything and > start condition OK >  sending Address ERROR. every time.

i tried changing pullups I2C speed and replaced chip. nothing got solved. 

 

Finally the problem was a button cell of RTC. i was trying all efforts without cell on board. after adding cell everything was perfect. Since then I'm using DS3231.

Trust is expensive u can never expect it from cheap ICs.

 

The DS1307 is a 100kHz bus device.   How can you expect it to work at 400kHz ?

The DS1307 shuts down its I2C interface if VCC falls below VBAT.

 

In practice,  you only want to talk to the DS1307 when you are alive and well.

The button cell keeps the RTC going when you (or the power supply) die.

 

David.

Last Edited: Thu. May 11, 2017 - 02:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

 

The DS1307 is a 100kHz bus device.   How can you expect it to work at 400kHz ?

The DS1307 shuts down its I2C interface if VCC falls below VBAT.

 

 

First thank you david to draw attention

and apology, wish i had posted this question in my old collage days. i could have saved my life's 36 hour :D