SC18IM704 does not work

[DHunt978]

SC18IM704 is not behaving properly in my system.  I am having a serious issue for months now, and it may be time for a re-spin.

The first issue I was seeing was a random drop of the write portion of an I2C read command.  Because I am speaking with a PCAL6416A, this was causing the wrong port to be read.  This was a bit annoying and hard to find, but eventually we nailed it down and found a way to ignore the erroneous reads.  It happens at such a rare frequency that a workaround is a feasible solution.

About one month later, I began seeing a far more serious issue on a lot of devices.  I am seeing that there is no I2C activity at all.  At this point, I raised a flag with NXP support to try to get them to take a look at this.  They told me my I2C pullup resistors were okay and to send the failed chips to NXP.  I performed ABA testing to prove the chips were failing, and waited a couple of months before NXP told me that the chips are out of warranty.  Well, in the meantime, I had bought replacement parts with a 2024 date code from Digikey and I am seeing all of the same behavior as with the 2022 lot.  This is especially a disaster because the basic functionality of a product in the field depends on these chips to work, and our manufacturing line is down.  I would recommend against using these parts on your products.  Develop the UART to I2C interface with a microcontroller instead.

[DHunt978]

I have found the cause of this problem.  The issue stems from the fact that I am pulling the I2C pins up to a different voltage rail than the chip VCC.  The SC18IM704 is the first device to come up in my system, before the downstream I2C devices.  When the rail that powers the I2C devices comes up, this can cause the SC18IM704 I2C to hang.  By attaching a wire to the SDA line and shorting it to ground, mimicking an I2C start and stop condition, I was able to recover the device. We have implemented a workaround by having the host put the device into sleep mode on discovery by sending "Z\x5A\xA5P".  

Because of this oddity and the oddities of some register writes causing the device to hang, I have still determined that it is a better long-term solution to implement the UART-to-I2C Bridge myself with the LPC802.  The LPC80X (LPC802) has a package that is pin-compatible with the SC18IM704PWJ.  NXP support did not help me discover this issue.  My manager, Berk, helped solved this problem.

Best Regards,

Dmitri

[DHunt978]

Hi Jozef,

I do not want to go down this path again with the CQI form.  I filled one out and waited a long time to get a response.  I want to work directly with an NXP engineer, or I will simply not use this product.  You have my contact information as well as the reports that I have filed with NXP. 

It's not enough to look at pullup resistors and ask for the chips back.  I need somebody to scrutinize my application and help me figure out why it is not working.  I believe the root cause of this failure should be of interest to NXP.

Best Regards,

Dmitri

[JozefKozon]

Hi Dmitri,

Yes, I have your contact information, but unfortunately I do not have reports that you have filled with NXP and I do not have access to them.

I have checked your schematics again and everything is correct. There is not much more to check by me on the schematic. Please state how many of the new SC18IM704 have you ordered and how many of them are failing. 

With Best Regards,

Jozef

[DHunt978]

 Hi Jozef,

I started a CQI on the 2022 lot and did not get a response for one month.  Our manufacturing line is down so I cannot wait for NXP.

If you are willing to have an FAE take a deeper look at this issue,  that would be welcome.  Otherwise, we will have to re-consider our entire system design.  Sending NXP chips does not help me fix my problem.

Best Regards,

Dmitri

[JozefKozon]

Dear Dimitri,

I am sorry to read, that the components are failing in your application. If the schematic was checked and is correct, please start a CQI (Customer Quality Incident). It is possible that the 2024 lot you have received is faulty. This needs to be checked by our quality engineers directly. The procedure is such, that you will contact the authorized distributor, in your case Digikey, they will let you fill CQC form, will take the failing components and sent them to NXP for analysis.

With Best Regards,

Jozef