We occasionally see incorrect values in PCA9555 registers 4 and 5 (the Polarity Inversion registers). Our software never intentionally writes to these registers and we rely on the power-on-reset circuit to properly initialize them.I had thought that we must have a software bug causing this, but then I read that the TCA9555 addresses a problem with power-on-reset with the PCA9555, so I am now pursuing that.
We power the PCA9555 off of a 3.3V supply and the supply ramps up linearly over 3mS. Shutdown is less well controlled, especially when the supply gets below 1V and takes around 5mS. We see this register corruption on about 3% of our products.
Does this seem like the type of problem that would be addressed by the TCA9555?
Stan,
To provide a good reset signal, the power-on-reset (POR) circuit of the PCA9555 requires a supply ramp time from 0V to VCC that is less than about 10ms. Also, to achieve a good reset, the POR circuit requires a powered-off (VCC<0.2V) duration of greater than ~700mS. You appear to meet the first condition, but I can't tell from your post whether you meet the second condition.
The TCA9555 addresses both of the above restrictions and should properly reset over a much wider set of conditions. The applications section of the TCA9555 datasheet provides information on the TCA9555 POR characteristics.
-Mark
Hello,
we are experiencing similar problems with PCA9555. The ramp is almost linearly rising from 0 to 3.3V in 4ms. At first startup, the PCA9555 doesn't work at all or only the lower 8 bit port is working (we have connected LEDs at both ports).This is weird enough: it seems, as if I2C is working, but the upper port is not...
Interestingly, all 4 I/O-expanders on the PCB show the same behaviour in parallel. If power is disconnected and reconnected within a few seconds, they get a propper power-on-reset and are then all working fine. A delay (PCB powered off) of more than 10 seconds gets the problem back again.
I have been finding an improvement in slowing down the rise-time of the supply voltage >> 500ms. However this doesn't guarantee reliable behaviour.
I also have been observing, that the PCA9555 seems to get a supply without its VCC connected (possibly through the clamping diodes, adress pins of I2C or I/O pins?). This also seems to corrupt the filtering on the dedicated VCC pin (1 Ohm resistor, decoupling capacitors). The PCA9555 gets its power just anywhere power is present: How can I really tell, what the power on reset detector is getting his ramp from?
I haven't been measuring any glitches, voltage is well filtered and monotonically rising.
The datasheet indicates a "no load condition" for the power on reset -voltage. How serious is that condition to be met? (If I have LEDs connected at the outputs, it's hard to guarantee a no load condition during power up).
Is there any know issue about the PCA9555? Is there any workaround to get them working somehow or forcing them to reset (without touching VCC)?
In what way do the PCA9555 from TI and NXP differ? Are they based on the very same die? Is there any hope to get a better result with TCA9555 like Stan proposed?
Thanks for your help,
Phil
Any chance for an answer...?
Hi Phil,
I never saw the lockup problem you describe where the upper port doesn't work at all.
I also verified that my power supplies meet the ramp up requirements, but I have no way to guarantee that the supply voltage drops below 0.2V between power cycles. Once my supply gets below 0.7V, there isn't much draw and it can take several seconds for it to leak down to below 0.2V.
I also have some I/O pins on the part which are hooked to other supplies, so there may be a parasitic power path that we are triggering.The Absolute Maximum Ratings on this part says -0.5 to 6V. I usually interpret that to mean I can raise the voltage on an I/O before applying power to the part without a latch-up issue, but that might not be the case on this part since there is a 100K resistor between each I/O and the power pin.
I rewrote my firmware to not rely on the POR working properly and then designed out this part.
Stan
Phil,
It is hard to say what exactly the reason might be for what you are seeing, without looking at your entire application setup. The easiest thing to do would be to replace the PCA9555 with a TCA9555 and see if your problem goes away. If it doesn't then we can look at other options. I'm sorry I don't have a more concrete answer at this time.
We are having similar issues. Could you please share how you rewrote your firmware not to rely on the POR?
Thanks!
Hi Owais,
Our firmware now immediately writes the default values to all of the registers in this part, rather than relying on the POR within the PCA9555.
I also removed TI from the AVL for this part. There are other vendors with a compatible part that have a less fussy POR.
Thanks Stan.
We will try this approach.
Would you mind sending me the part# of the part that you are now using and are having success with. Fortunately we are at the time in the project that we can make this change before production begins. You can PM me to oahmad@atitest.com.
Thanks Again!