SC18IM704 internal register 7, 8 and 9 write freezes chip access

[Marcel2]

There is a problem writing to the internal registers of the SC18IM704 UART to I2C-bus bridge. The chip has 11 internal registers. All the registers can be read:

Status: 0xf0 (0xf0 = ok)
Bytes read: 11 f00255554d0026130066f0

The first 7 (0x00 to 0x06) can be written, however writing to any of the registers above (0x07 to 0x09) will render the chip unresponsive. A power cycle is required to recover access again.

During development of the software we have used an eval board with the same chip which does not have this problem. We noticed a firmware/version difference while reading the chip identification string.

OWN_HW:      ID: (16) 53433138494d37303420312e302e3200 b'SC18IM704 1.0.2\x00'
EVAL_BD:       ID: (16) 53433138494d37303420312e302e3200 b'SC18IM704 1.0.1\x00'

If we don't write to these registers and leave the I2C speed at 100kHz all others communications work properly.

[Marcel2]

Hi Jozef,

Reading the status register (reg 0x0a) reads a value of 0xf0 (already shown)

[JozefKozon]

Dear Marcel,

please share your schematic with voltage levels and part values. 

With Best Regards,

Jozef

[Marcel2]

See above schematics, both SCIM704 devices have the same problem

[JozefKozon]

Hi Marcel,

please try to decrease pull-up resistor values for the SDA and SCL lines. The 5.1kOhm pull-up might be ok for the 100kHz communication speed, but for higher communication speed they might be too high. Please use 3kOhm pull-up resistors instead and see if it helps. Please see my calculations below.

For the communication speed of 100kHz maximum allowed rise time is tr=1000ns. For the 400kHz, tr=300ns.

The Cb is a bus capacitance of the SDA and SCL lines. The lower, the better. Each device adds some capacitance to the lines. The SC18IM704 adds maximally 15pF. 

The PCA9540B adds maximally 8pF per line. 

Then the PCB traces and/or cables adds capacitance to the SDA and SCL lines. This can be only estimated (shorter=lower capacitance). I have calculated the pull-up resistor values for bus capacitance Cb=100pF. The 15pF+8pF=23pF and the PCB traces and cables capacitance 77pF.

Rp(max)=tr/(0.8473*Cb)

For 100kHz.

Rp(max)=1000ns/(0.8473*100pF)=11.8kOhm. The 5.1kOhm is way lower and is ok.

For 400kHz.

Rp(max)=300ns/(0.8473*100pF)=3.54kOhm. The 5.1kOhm exceeds the Rp(max).

For the Rp(min), you can read the minimum required pull-up resistor values from the graph in the Figure 42. The 100kHz is Standard-mode and the 400kHz is Fast-mode. The supply voltage limits the minimum value of resistor Rp due to the specified minimum sink current of 3 mA for Standard-mode and Fast-mode. So the minimum required pull-up resistor value for both is approximately 1kOhm. 

With Best Regards,

Jozef

[Marcel2]

Hi Jozef,

Thanks for looking into our problem. We have replaced the pullup resistors with 1kOhm. This however did not make any improvement to the freezing problem.

Note that a write without changing the value (writing the same value back as read) does also freeze the chip.

Is there a revision history with the changes between version 1.01 and 1.02?

Any new ideas?

[JozefKozon]

Hi Marcel,

I have contacted an application engineer dealing with the UART to I2C bridges. He confirmed, that this is a known issue. I have provided him your phone and email. He will send you samples of the fixed SC18IM704s.

DESCRIPTION

This issue has been confirmed and we are working to get it fix. I will let you know when the fixed version of the IM704 are ready. I can send some samples to the customer at that time too.

With Best Regards,

Jozef

[Marcel2]

Hi Jozef,

Have you any idea when a solution will be available? Can you send me (by PM) the email address of the application engineer?

Regards Marcel

[JozefKozon]

Hi Marcel,

I have asked the application engineer if I can share his email address with you. Unfortunately he hadn't agreed. As soon as the application engineer sends me an update, I will definitely reply to you. In case it will take too long, please create a new ticket in here. Please mention there this case #00510991 and we will know, to what the new case is related. Please see below for the application engineer's answer.

DESCRIPTION

I would like you to be the first contact. When I have the updated device I will let you know. The test engineering is working on the procedure to flash the device correctly at production.

With Best Regards,

Jozef

[JozefKozon]

Hi Marcel,

there is still no answer from the application engineer. As soon as I receive one, I will definitely reply to you. Thank you for your patience.

With Best Regards,

Jozef

[Marcel2]

Hi Jozef,

Thanks for keeping me posted. Hopefully we will get an answer soon.

Regards,
Marcel

[JozefKozon]

Hi Marcel,

please see below an answer from the application engineer. 

I apologize for inconvenience.

DESCRIPTION

The latest information for the production/test engineer is that a limited updated version to fix this issue will be shipped to San Jose at the end of 2/2023. These will be tested to make sure the issue is fixed before the production start. It will be awhile, probably mid 2023, before the SC18IM704 are available to the customers to order. The device has to go through the normal production process first.

With Best Regards,

Jozef

[Tix00]

Hi! we bought an SC18IM704 a few days ago, hoping the new release but it's still marked as 1.0.2 firmware. When will be available a revised version?

[alanm]

Hi Josef,

I'm facing the same problems reported by Marcel while testing the SC18IM704-EVB.

The 'VP' command reply is 'SC18IM704 1.0.2\x00'

Is there a know workaround to reset the device remotely apart from not accessing the problematic registers? Can you please share the ERRATA regarding this issue?

Can you please keep me updated regarding the status of the fixed IC version and provide samples when available?

Many thanks,

Alan

[JozefKozon]

Dear Marcel,

please also provide reading from the 0x0A I2CStat register.

With Best Regards,

Jozef