DS90UB953A-Q1: Missing stop bit at i2c with DS90UB953 and DS90UB954

Frank H

Part Number: DS90UB953A-Q1
Other Parts Discussed in Thread: LSF0204, USB2ANY

Team,

we’re using DS90UB953 and DS90UB954 for our application. Now we have a problem with I2C uplink from DS90UB954 to DS90UB953.

It seems, that after sending a message to upstream device the DS90UB953 holds the I2C SDA and SCL on low although there was a stop bit at the DS90UB954. When the next start bit appears at the DS90UB954 the DS90UB953 releases both signals and sends a start bit as well but somehow our communication crashes because of this and the upstream device gets some wrong values in wrong registers. Is this issue known and how could we achieve the right transmission of the stop bit?

Is there already a solution to this problem or is there just something wrong with our initialization? Would it make sense to have a call about this problem?

Greetings,

Frank

over 2 years ago

0 Christian Brey over 2 years ago

Prodigy 170 points

Just an update un this issue:
this error only occurs after ~100 successful communication packets were sent. It's always just a missing stop bit on the i2c bus after the serialiser. On the deserialiser it is still there.

greetings

Christian

0 Glenn Uranga over 2 years ago in reply to Christian Brey

TI__Genius 16230 points

Hi Christian,

Can you please let me know what you are programming the 0x0A register on the 953?

We might need to speed up the watchdog timer. Can you write 0x12 to register 0x0A on the 953?

Glenn

0 Christian Brey over 2 years ago in reply to Glenn Uranga

Prodigy 170 points

Hi Glenn,

thank you for your fast answer, we did some investigations with your suggested settings but it had no effect.

Here some pictures from the I2C bus at the 953:

compared to what we could see at the 954:

yellow = scl
pink = sda

I guess the problem is the remaining low SDA and SCL after the first five packets at 953 while it's high at the 954 (as expected).

Why are SDA and SCL held low?

Christian

0 Zoe Bison over 2 years ago in reply to Christian Brey

TI__Mastermind 23685 points

Hi Christian,

I would like to clarify the following details regarding the set up:

Is synchronous or non-synchronous mode being used?
When the issue occurs in I2C communication, is there any change in register 0x4D or a loss of lock between the 953A and 954?
1. LOCK status can be monitored on a GPIO pin and check whether it goes low whenever you see the I2C issue.
Would you be able to provide a register dump of the 954 when it is experiencing this issue?

Best,

Zoe

0 Christian Brey over 2 years ago in reply to Zoe Bison

Prodigy 170 points

Hi Zoe,

1. we are using synchronous mode

2. there were no status changes on the fpd link lock pin

3. Register dump will be available soon

Best,

Christian

0 Christian Brey over 2 years ago in reply to Christian Brey

Prodigy 170 points

Thes are some files with the dumped register values in it

Serialiser 953 OK:

Fullscreen serdes_serializer.txt Download

0x0: 0x32
0x1: 0x00
0x2: 0x13
0x3: 0x48
0x4: 0x00
0x5: 0x03
0x6: 0x41
0x7: 0x14
0x8: 0xfe
0x9: 0x1e
0xA: 0x10
0xB: 0x13
0xC: 0x26
0xD: 0x70
0xE: 0x70
0xF: 0x00
0x10: 0x00
0x11: 0x00
0x12: 0x00
0x13: 0x00
0x14: 0x00
0x15: 0x20
0x16: 0x18
0x17: 0x3c
0x18: 0x80
0x19: 0x62
0x1A: 0x62
0x1B: 0x62
0x1C: 0x00
0x1D: 0x00
0x1E: 0x00
0x1F: 0x00
0x20: 0x00
0x21: 0x00
0x22: 0x00
0x23: 0x00
0x24: 0x00
0x25: 0x02
0x26: 0x00
0x27: 0x00
0x28: 0x67
0x29: 0x33
0x2A: 0x01
0x2B: 0x00
0x2C: 0x00
0x2D: 0x00
0x2E: 0x00
0x2F: 0x00
0x30: 0x00
0x31: 0x20
0x32: 0x09
0x33: 0x04
0x34: 0x00
0x35: 0x11
0x36: 0x00
0x37: 0x60
0x38: 0x00
0x39: 0x00
0x3A: 0x00
0x3B: 0x00
0x3C: 0x00
0x3D: 0x00
0x3E: 0x00
0x3F: 0x00
0x40: 0x00
0x41: 0x00
0x42: 0x00
0x43: 0x00
0x44: 0x00
0x45: 0x00
0x46: 0x00
0x47: 0x00
0x48: 0x00
0x49: 0x00
0x4A: 0x00
0x4B: 0x00
0x4C: 0x00
0x4D: 0x00
0x4E: 0x00
0x4F: 0x00
0x50: 0x20
0x51: 0xc0
0x52: 0x45
0x53: 0x00
0x54: 0x00
0x55: 0x00
0x56: 0x00
0x57: 0x00
0x58: 0x07
0x59: 0x07
0x5A: 0x07
0x5B: 0x00
0x5C: 0x00
0x5D: 0x00
0x5E: 0x00
0x5F: 0x00
0x60: 0x02
0x61: 0x2c
0x62: 0x50
0x63: 0x01
0x64: 0x2b
0x65: 0x98
0x66: 0x00
0x67: 0x00
0x68: 0x00
0x69: 0x00
0x6A: 0x00
0x6B: 0x00
0x6C: 0x00
0x6D: 0x00
0x6E: 0x00
0x6F: 0x00
0x70: 0x00
0x71: 0x00
0x72: 0x25
0x73: 0x00
0x74: 0x00
0x75: 0x00
0x76: 0x00
0x77: 0x00
0x78: 0x00
0x79: 0x00
0x7A: 0xe4
0x7B: 0x00
0x7C: 0x00
0x7D: 0x00
0x7E: 0x00
0x7F: 0x00
0x80: 0x00
0x81: 0x00
0x82: 0x00
0x83: 0x00
0x84: 0x00
0x85: 0x00
0x86: 0x90
0x87: 0x00
0x88: 0x00
0x89: 0x00
0x8A: 0x00
0x8B: 0x00
0x8C: 0x06
0x8D: 0x00
0x8E: 0x00
0x8F: 0x00
0x90: 0x32
0x91: 0xe3
0x92: 0x64
0x93: 0x01
0x94: 0x00
0x95: 0x00
0x96: 0x00
0x97: 0x00
0x98: 0x00
0x99: 0x00
0x9A: 0x02
0x9B: 0x02
0x9C: 0x22
0x9D: 0x00
0x9E: 0x00
0x9F: 0x11
0xA0: 0x00
0xA1: 0x0e
0xA2: 0x10
0xA3: 0x0f
0xA4: 0x0e
0xA5: 0x10
0xA6: 0x42
0xA7: 0x10
0xA8: 0x10
0xA9: 0x10
0xAA: 0x03
0xAB: 0x01
0xAC: 0x00
0xAD: 0x00
0xAE: 0x00
0xAF: 0x00
0xB0: 0x04
0xB1: 0x4a
0xB2: 0x3f
0xB3: 0x00
0xB4: 0x00
0xB5: 0x00
0xB6: 0x00
0xB7: 0x00
0xB8: 0x00
0xB9: 0x00
0xBA: 0x00
0xBB: 0x00
0xBC: 0x00
0xBD: 0x00
0xBE: 0x00
0xBF: 0x00
0xC0: 0x00
0xC1: 0x00
0xC2: 0x00
0xC3: 0x00
0xC4: 0x00
0xC5: 0x00
0xC6: 0x00
0xC7: 0x00
0xC8: 0x00
0xC9: 0x00
0xCA: 0x00
0xCB: 0x00
0xCC: 0x00
0xCD: 0x00
0xCE: 0x00
0xCF: 0x00
0xD0: 0x00
0xD1: 0x00
0xD2: 0x00
0xD3: 0x00
0xD4: 0x00
0xD5: 0x00
0xD6: 0x00
0xD7: 0x00
0xD8: 0x00
0xD9: 0x00
0xDA: 0x00
0xDB: 0x00
0xDC: 0x00
0xDD: 0x00
0xDE: 0x00
0xDF: 0x00
0xE0: 0x00
0xE1: 0x00
0xE2: 0x00
0xE3: 0x00
0xE4: 0x00
0xE5: 0x00
0xE6: 0x00
0xE7: 0x00
0xE8: 0x00
0xE9: 0x00
0xEA: 0x00
0xEB: 0x00
0xEC: 0x00
0xED: 0x00
0xEE: 0x00
0xEF: 0x00
0xF0: 0x5f
0xF1: 0x55
0xF2: 0x42
0xF3: 0x39
0xF4: 0x35
0xF5: 0x33
0xF6: 0x00
0xF7: 0x00
0xF8: 0x00
0xF9: 0x00
0xFA: 0x00
0xFB: 0x00
0xFC: 0x00
0xFD: 0x00
0xFE: 0x00
0xFF: 0x00

Deserialiser 954 OK:

Fullscreen serdes_deserializer.txt Download

0x0: 0x60
0x1: 0x00
0x2: 0x1e
0x3: 0x20
0x4: 0xdf
0x5: 0x01
0x6: 0x00
0x7: 0xfe
0x8: 0x1c
0x9: 0x10
0xA: 0x7a
0xB: 0x7a
0xC: 0x97
0xD: 0x09
0xE: 0x00
0xF: 0x77
0x10: 0x00
0x11: 0x00
0x12: 0x00
0x13: 0xd1
0x14: 0x00
0x15: 0x00
0x16: 0x00
0x17: 0x00
0x18: 0x00
0x19: 0x00
0x1A: 0x00
0x1B: 0x00
0x1C: 0x00
0x1D: 0x00
0x1E: 0x04
0x1F: 0x00
0x20: 0x00
0x21: 0x01
0x22: 0x00
0x23: 0x83
0x24: 0x00
0x25: 0x00
0x26: 0x00
0x27: 0x00
0x28: 0x00
0x29: 0x00
0x2A: 0x00
0x2B: 0x00
0x2C: 0x00
0x2D: 0x00
0x2E: 0x00
0x2F: 0x00
0x30: 0x00
0x31: 0x00
0x32: 0x00
0x33: 0x43
0x34: 0x41
0x35: 0x01
0x36: 0x00
0x37: 0x01
0x38: 0x00
0x39: 0x00
0x3A: 0x00
0x3B: 0x01
0x3C: 0x14
0x3D: 0x6f
0x3E: 0x00
0x3F: 0x40
0x40: 0x00
0x41: 0xa9
0x42: 0x71
0x43: 0x01
0x44: 0x00
0x45: 0x00
0x46: 0x00
0x47: 0x00
0x48: 0x00
0x49: 0x00
0x4A: 0x00
0x4B: 0x12
0x4C: 0x10
0x4D: 0x43
0x4E: 0x04
0x4F: 0x64
0x50: 0x00
0x51: 0x00
0x52: 0x00
0x53: 0x04
0x54: 0x00
0x55: 0x00
0x56: 0x00
0x57: 0x00
0x58: 0x5e
0x59: 0x00
0x5A: 0x00
0x5B: 0x32
0x5C: 0x7c
0x5D: 0xa0
0x5E: 0xa8
0x5F: 0xaa
0x60: 0xa2
0x61: 0x7a
0x62: 0x00
0x63: 0x00
0x64: 0x00
0x65: 0xa6
0x66: 0xa8
0x67: 0xaa
0x68: 0xc0
0x69: 0xc2
0x6A: 0x00
0x6B: 0x00
0x6C: 0x00
0x6D: 0x7c
0x6E: 0x98
0x6F: 0x82
0x70: 0x6b
0x71: 0x6c
0x72: 0x55
0x73: 0x0a
0x74: 0xd0
0x75: 0x01
0x76: 0x50
0x77: 0xc5
0x78: 0x00
0x79: 0x01
0x7A: 0x00
0x7B: 0x00
0x7C: 0x20
0x7D: 0x00
0x7E: 0x00
0x7F: 0x00
0x80: 0x00
0x81: 0x00
0x82: 0x00
0x83: 0x00
0x84: 0x00
0x85: 0x00
0x86: 0x00
0x87: 0x00
0x88: 0x00
0x89: 0x00
0x8A: 0x00
0x8B: 0x00
0x8C: 0x00
0x8D: 0x00
0x8E: 0x00
0x8F: 0x00
0x90: 0x00
0x91: 0x00
0x92: 0x00
0x93: 0x00
0x94: 0x00
0x95: 0x00
0x96: 0x00
0x97: 0x00
0x98: 0x00
0x99: 0x00
0x9A: 0x00
0x9B: 0x00
0x9C: 0x00
0x9D: 0x00
0x9E: 0x00
0x9F: 0x00
0xA0: 0x02
0xA1: 0x0f
0xA2: 0x00
0xA3: 0x00
0xA4: 0x08
0xA5: 0x19
0xA6: 0x00
0xA7: 0x00
0xA8: 0x00
0xA9: 0x00
0xAA: 0x00
0xAB: 0x00
0xAC: 0x00
0xAD: 0x00
0xAE: 0x00
0xAF: 0x00
0xB0: 0x08
0xB1: 0x14
0xB2: 0x3f
0xB3: 0x08
0xB4: 0x25
0xB5: 0x00
0xB6: 0x18
0xB7: 0x00
0xB8: 0x8c
0xB9: 0x33
0xBA: 0x83
0xBB: 0x74
0xBC: 0x80
0xBD: 0x00
0xBE: 0x7f
0xBF: 0x00
0xC0: 0x00
0xC1: 0x00
0xC2: 0x00
0xC3: 0x00
0xC4: 0x00
0xC5: 0x00
0xC6: 0x00
0xC7: 0x00
0xC8: 0x00
0xC9: 0x00
0xCA: 0x00
0xCB: 0x00
0xCC: 0x00
0xCD: 0x00
0xCE: 0x00
0xCF: 0x00
0xD0: 0x00
0xD1: 0x43
0xD2: 0x94
0xD3: 0x02
0xD4: 0x60
0xD5: 0xf2
0xD6: 0x00
0xD7: 0x02
0xD8: 0x07
0xD9: 0x7f
0xDA: 0x00
0xDB: 0x00
0xDC: 0x00
0xDD: 0x00
0xDE: 0x00
0xDF: 0x00
0xE0: 0x00
0xE1: 0x00
0xE2: 0x00
0xE3: 0x00
0xE4: 0x00
0xE5: 0x00
0xE6: 0x00
0xE7: 0x00
0xE8: 0x00
0xE9: 0x00
0xEA: 0x00
0xEB: 0x00
0xEC: 0x00
0xED: 0x00
0xEE: 0x00
0xEF: 0x00
0xF0: 0x5f
0xF1: 0x55
0xF2: 0x42
0xF3: 0x39
0xF4: 0x35
0xF5: 0x34
0xF6: 0x00
0xF7: 0x00
0xF8: 0x80
0xF9: 0x82
0xFA: 0x00
0xFB: 0x00
0xFC: 0x00
0xFD: 0x00
0xFE: 0x00
0xFF: 0x00

Serialiser 953 FAIL:

Fullscreen serdes_serializer.txt Download

0x0: 0x32
0x1: 0x00
0x2: 0x13
0x3: 0x48
0x4: 0x00
0x5: 0x03
0x6: 0x41
0x7: 0x14
0x8: 0xfe
0x9: 0x1e
0xA: 0x10
0xB: 0x13
0xC: 0x26
0xD: 0x70
0xE: 0x70
0xF: 0x00
0x10: 0x00
0x11: 0x00
0x12: 0x00
0x13: 0x00
0x14: 0x00
0x15: 0x20
0x16: 0x18
0x17: 0x3c
0x18: 0x80
0x19: 0x62
0x1A: 0x62
0x1B: 0x62
0x1C: 0x00
0x1D: 0x00
0x1E: 0x00
0x1F: 0x00
0x20: 0x00
0x21: 0x00
0x22: 0x00
0x23: 0x00
0x24: 0x00
0x25: 0x02
0x26: 0x00
0x27: 0x00
0x28: 0x67
0x29: 0x33
0x2A: 0x01
0x2B: 0x00
0x2C: 0x00
0x2D: 0x00
0x2E: 0x00
0x2F: 0x00
0x30: 0x00
0x31: 0x20
0x32: 0x09
0x33: 0x04
0x34: 0x00
0x35: 0x11
0x36: 0x00
0x37: 0x60
0x38: 0x00
0x39: 0x00
0x3A: 0x00
0x3B: 0x00
0x3C: 0x00
0x3D: 0x00
0x3E: 0x00
0x3F: 0x00
0x40: 0x00
0x41: 0x00
0x42: 0x00
0x43: 0x00
0x44: 0x00
0x45: 0x00
0x46: 0x00
0x47: 0x00
0x48: 0x00
0x49: 0x00
0x4A: 0x00
0x4B: 0x00
0x4C: 0x00
0x4D: 0x00
0x4E: 0x00
0x4F: 0x00
0x50: 0x20
0x51: 0xc0
0x52: 0x45
0x53: 0x00
0x54: 0x00
0x55: 0x00
0x56: 0x00
0x57: 0x00
0x58: 0x07
0x59: 0x07
0x5A: 0x07
0x5B: 0x00
0x5C: 0x00
0x5D: 0x00
0x5E: 0x00
0x5F: 0x00
0x60: 0x02
0x61: 0x2c
0x62: 0x50
0x63: 0x01
0x64: 0x2b
0x65: 0x98
0x66: 0x00
0x67: 0x00
0x68: 0x00
0x69: 0x00
0x6A: 0x00
0x6B: 0x00
0x6C: 0x00
0x6D: 0x00
0x6E: 0x00
0x6F: 0x00
0x70: 0x00
0x71: 0x00
0x72: 0x25
0x73: 0x00
0x74: 0x00
0x75: 0x00
0x76: 0x00
0x77: 0x00
0x78: 0x00
0x79: 0x00
0x7A: 0xe4
0x7B: 0x00
0x7C: 0x00
0x7D: 0x00
0x7E: 0x00
0x7F: 0x00
0x80: 0x00
0x81: 0x00
0x82: 0x00
0x83: 0x00
0x84: 0x00
0x85: 0x00
0x86: 0x90
0x87: 0x00
0x88: 0x00
0x89: 0x00
0x8A: 0x00
0x8B: 0x00
0x8C: 0x06
0x8D: 0x00
0x8E: 0x00
0x8F: 0x00
0x90: 0x32
0x91: 0xe3
0x92: 0x64
0x93: 0x01
0x94: 0x00
0x95: 0x00
0x96: 0x00
0x97: 0x00
0x98: 0x00
0x99: 0x00
0x9A: 0x02
0x9B: 0x02
0x9C: 0x22
0x9D: 0x00
0x9E: 0x00
0x9F: 0x11
0xA0: 0x00
0xA1: 0x0e
0xA2: 0x10
0xA3: 0x0f
0xA4: 0x0e
0xA5: 0x10
0xA6: 0x42
0xA7: 0x10
0xA8: 0x10
0xA9: 0x10
0xAA: 0x03
0xAB: 0x01
0xAC: 0x00
0xAD: 0x00
0xAE: 0x00
0xAF: 0x00
0xB0: 0x04
0xB1: 0x4a
0xB2: 0x3f
0xB3: 0x00
0xB4: 0x00
0xB5: 0x00
0xB6: 0x00
0xB7: 0x00
0xB8: 0x00
0xB9: 0x00
0xBA: 0x00
0xBB: 0x00
0xBC: 0x00
0xBD: 0x00
0xBE: 0x00
0xBF: 0x00
0xC0: 0x00
0xC1: 0x00
0xC2: 0x00
0xC3: 0x00
0xC4: 0x00
0xC5: 0x00
0xC6: 0x00
0xC7: 0x00
0xC8: 0x00
0xC9: 0x00
0xCA: 0x00
0xCB: 0x00
0xCC: 0x00
0xCD: 0x00
0xCE: 0x00
0xCF: 0x00
0xD0: 0x00
0xD1: 0x00
0xD2: 0x00
0xD3: 0x00
0xD4: 0x00
0xD5: 0x00
0xD6: 0x00
0xD7: 0x00
0xD8: 0x00
0xD9: 0x00
0xDA: 0x00
0xDB: 0x00
0xDC: 0x00
0xDD: 0x00
0xDE: 0x00
0xDF: 0x00
0xE0: 0x00
0xE1: 0x00
0xE2: 0x00
0xE3: 0x00
0xE4: 0x00
0xE5: 0x00
0xE6: 0x00
0xE7: 0x00
0xE8: 0x00
0xE9: 0x00
0xEA: 0x00
0xEB: 0x00
0xEC: 0x00
0xED: 0x00
0xEE: 0x00
0xEF: 0x00
0xF0: 0x5f
0xF1: 0x55
0xF2: 0x42
0xF3: 0x39
0xF4: 0x35
0xF5: 0x33
0xF6: 0x00
0xF7: 0x00
0xF8: 0x00
0xF9: 0x00
0xFA: 0x00
0xFB: 0x00
0xFC: 0x00
0xFD: 0x00
0xFE: 0x00
0xFF: 0x00

Deserialiser 954 FAIL:

Fullscreen serdes_deserializer.txt Download

0x0: 0x60
0x1: 0x00
0x2: 0x1e
0x3: 0x20
0x4: 0xdf
0x5: 0x01
0x6: 0x00
0x7: 0xfe
0x8: 0x1c
0x9: 0x10
0xA: 0x7a
0xB: 0x7a
0xC: 0x97
0xD: 0x09
0xE: 0x00
0xF: 0x77
0x10: 0x00
0x11: 0x00
0x12: 0x00
0x13: 0xd1
0x14: 0x00
0x15: 0x00
0x16: 0x00
0x17: 0x00
0x18: 0x00
0x19: 0x00
0x1A: 0x00
0x1B: 0x00
0x1C: 0x00
0x1D: 0x00
0x1E: 0x04
0x1F: 0x00
0x20: 0x00
0x21: 0x01
0x22: 0x00
0x23: 0x83
0x24: 0x00
0x25: 0x00
0x26: 0x00
0x27: 0x00
0x28: 0x00
0x29: 0x00
0x2A: 0x00
0x2B: 0x00
0x2C: 0x00
0x2D: 0x00
0x2E: 0x00
0x2F: 0x00
0x30: 0x00
0x31: 0x00
0x32: 0x00
0x33: 0x43
0x34: 0x41
0x35: 0x01
0x36: 0x00
0x37: 0x01
0x38: 0x00
0x39: 0x00
0x3A: 0x00
0x3B: 0x01
0x3C: 0x14
0x3D: 0x6f
0x3E: 0x00
0x3F: 0x40
0x40: 0x00
0x41: 0xa9
0x42: 0x71
0x43: 0x01
0x44: 0x00
0x45: 0x00
0x46: 0x00
0x47: 0x00
0x48: 0x00
0x49: 0x00
0x4A: 0x00
0x4B: 0x12
0x4C: 0x10
0x4D: 0x43
0x4E: 0x04
0x4F: 0x64
0x50: 0x00
0x51: 0x00
0x52: 0x00
0x53: 0x04
0x54: 0x00
0x55: 0x00
0x56: 0x00
0x57: 0x00
0x58: 0x5e
0x59: 0x00
0x5A: 0x00
0x5B: 0x32
0x5C: 0x7c
0x5D: 0xa0
0x5E: 0xa8
0x5F: 0xaa
0x60: 0xa2
0x61: 0x7a
0x62: 0x00
0x63: 0x00
0x64: 0x00
0x65: 0xa6
0x66: 0xa8
0x67: 0xaa
0x68: 0xc0
0x69: 0xc2
0x6A: 0x00
0x6B: 0x00
0x6C: 0x00
0x6D: 0x7c
0x6E: 0x98
0x6F: 0x82
0x70: 0x6b
0x71: 0x6c
0x72: 0x55
0x73: 0x0a
0x74: 0xd0
0x75: 0x01
0x76: 0x50
0x77: 0xc5
0x78: 0x00
0x79: 0x01
0x7A: 0x00
0x7B: 0x00
0x7C: 0x20
0x7D: 0x00
0x7E: 0x00
0x7F: 0x00
0x80: 0x00
0x81: 0x00
0x82: 0x00
0x83: 0x00
0x84: 0x00
0x85: 0x00
0x86: 0x00
0x87: 0x00
0x88: 0x00
0x89: 0x00
0x8A: 0x00
0x8B: 0x00
0x8C: 0x00
0x8D: 0x00
0x8E: 0x00
0x8F: 0x00
0x90: 0x00
0x91: 0x00
0x92: 0x00
0x93: 0x00
0x94: 0x00
0x95: 0x00
0x96: 0x00
0x97: 0x00
0x98: 0x00
0x99: 0x00
0x9A: 0x00
0x9B: 0x00
0x9C: 0x00
0x9D: 0x00
0x9E: 0x00
0x9F: 0x00
0xA0: 0x02
0xA1: 0x0f
0xA2: 0x00
0xA3: 0x00
0xA4: 0x08
0xA5: 0x19
0xA6: 0x00
0xA7: 0x00
0xA8: 0x00
0xA9: 0x00
0xAA: 0x00
0xAB: 0x00
0xAC: 0x00
0xAD: 0x00
0xAE: 0x00
0xAF: 0x00
0xB0: 0x08
0xB1: 0x14
0xB2: 0x3f
0xB3: 0x08
0xB4: 0x25
0xB5: 0x00
0xB6: 0x18
0xB7: 0x00
0xB8: 0x8c
0xB9: 0x33
0xBA: 0x83
0xBB: 0x74
0xBC: 0x80
0xBD: 0x00
0xBE: 0x7f
0xBF: 0x00
0xC0: 0x00
0xC1: 0x00
0xC2: 0x00
0xC3: 0x00
0xC4: 0x00
0xC5: 0x00
0xC6: 0x00
0xC7: 0x00
0xC8: 0x00
0xC9: 0x00
0xCA: 0x00
0xCB: 0x00
0xCC: 0x00
0xCD: 0x00
0xCE: 0x00
0xCF: 0x00
0xD0: 0x00
0xD1: 0x43
0xD2: 0x94
0xD3: 0x02
0xD4: 0x60
0xD5: 0xf2
0xD6: 0x00
0xD7: 0x02
0xD8: 0x07
0xD9: 0x7f
0xDA: 0x00
0xDB: 0x00
0xDC: 0x00
0xDD: 0x00
0xDE: 0x00
0xDF: 0x00
0xE0: 0x00
0xE1: 0x00
0xE2: 0x00
0xE3: 0x00
0xE4: 0x00
0xE5: 0x00
0xE6: 0x00
0xE7: 0x00
0xE8: 0x00
0xE9: 0x00
0xEA: 0x00
0xEB: 0x00
0xEC: 0x00
0xED: 0x00
0xEE: 0x00
0xEF: 0x00
0xF0: 0x5f
0xF1: 0x55
0xF2: 0x42
0xF3: 0x39
0xF4: 0x35
0xF5: 0x34
0xF6: 0x00
0xF7: 0x00
0xF8: 0x80
0xF9: 0x82
0xFA: 0x00
0xFB: 0x00
0xFC: 0x00
0xFD: 0x00
0xFE: 0x00
0xFF: 0x00

0 Christian Brey over 2 years ago in reply to Zoe Bison

Prodigy 170 points

Here an overview of the i2c communication the both upper gaphs are the scl (green) and the sda (purple) at the 954 and the lower two are scl (red) and sda (yellow) of the 953.

the part I am concerned abotu is after the 10th clock package, where the scl and sda were going high at the 954 with an stop condition while both signals remain low at the 953.

This picture is just further zoom in at the described position.

Best,

Christian

0 Christian Brey over 2 years ago in reply to Christian Brey

Prodigy 170 points

Here is a picture of what I was expecting instead.
There is clearly a stop bit and then a new start for the next packets sent.

0 Christian Brey over 2 years ago in reply to Christian Brey

Prodigy 170 points

The differences I could find there where:

Serialiser 953:
Register    OK               FAIL
0x52           0x45            0x47
0x55           0x00            0xff
0x56           0x00            0xff

0x60    0x02   0x00

Deserialiser 954:
Register OK FAIL
0x37: 0x010 0x00

0 Zoe Bison over 2 years ago in reply to Christian Brey

TI__Mastermind 23685 points

Hi Christian,

In the good case for the 953, no back channel CRC errors are reported. In the bad case, these errors are maxed out. Typically back channel errors would create forward channel errors reported on the deserializer due to the forward channel being created from the back channel.

Are there any other I2C controlled devices or controllers on the stream that may be conflicting?

Best,

Zoe

0 Christian Brey over 2 years ago in reply to Zoe Bison

Prodigy 170 points

Hi Zoe,

there are in deed some more devices on the bus but they should not be conflicting.
Here is the block diagram of our application.

The CRC errors is what I was also concerned about but how could they appear that often without loosing the fpd-link?
And why is the only I2C error we could see the missing stop bit and no other data errors? Is there a statemachine running behind, which sometimes looses this stop bit if the next device adress for writing is the same as the pervious one?

Best,

Christian

0 Zoe Bison over 2 years ago in reply to Christian Brey

TI__Mastermind 23685 points

Hi Christian,

Since the BC CRC errors are not causing a loss of lock, these errors may simply be occurring during start-up and weren't cleared properly. These values will be cleared by reading register 0x49.

Reviewing the scope shots, it is clear the abnormal transaction is not creating a valid stop condition on the 953.

To locate the potential source of the issue, I have the following questions:

Do the transactions behave abnormally following the same I2C transaction? If so, what device is the target of this transaction?
What type of transactions are being sent? Is I2C burst pass through being used?
Would you be able to provide scope shots of the 953 sending I2C transactions to each target?
1. The purpose of this will be to see if the issue is isolated to one of the downstream devices since the 953 may not be in control of the I2C transaction.

When SDA and SCL are held low at the same time, more data is expected to be sent on the I2C line. In the scope provided, the stop condition is not observed on the 953 SCL and SDA lines. It is possible then that the watchdog timer on the other devices is not being asserted to end the transaction prior to the new one.

Best,

Zoe

0 Christian Brey over 2 years ago in reply to Zoe Bison

Prodigy 170 points

Hi Zoe,

1. There are two I2C errors we could detect on the bus because they lead to more serious errors and these are both while communication with the imager, that's exactly what you can see at scope shots. Sometimes this error happens after the first 5 packets and sometimes after the second 5 packets.

2. We don't use burst mode.

3. Since we were only able to trigger on this error during imager communication so far I cand send you pictures of the error with other devices on the bus but I'll check for it.

The thing with the watchdog on the imager was something I was also thinking of but never checked it because it seems like the next start bit comes at the same time after the first 5 packets no matter if the errror occurs or not. So why should the imager know after which time it has to release SDA and SCL because the 953 wants to send data again? But I will check it as well.

Please let me know if you need any further information.

Thanks for your support so far and have a nice weekend

Christian

0 Hamzeh Jaradat over 2 years ago in reply to Christian Brey

TI__Guru** 107810 points

Hello Christian,

Zoe is OoO and will be back after the Public Holiday, on Tuesday.

0 Zoe Bison over 2 years ago in reply to Christian Brey

TI__Mastermind 23685 points

Hi Christian,

Thank you for the clarification. Has the imager communication been tested with only the imager on the bus? My point of interest with this question is to distinguish if the level shifter may be impacting the I2C communication bus.

Best,

Zoe

0 Christian Brey over 2 years ago in reply to Zoe Bison

Prodigy 170 points

There are some issuers with other devices as well that's what I could see for ICC communication:

yellow -> SCL HEAD
pink -> SDA HEAD
blue -> SCL VPU
green -> SDA VPU

There is a stop condition after the last command, on the VPU followed by a stop condition on the HEAD. Then there is a start condition on the VPU with a register value which is also sent at the head afterwards. But why is the Head answering at this condition immediately? Shouldn’t it wait for another register value?

Then the communication goes on and the ICC sends more and more registers, the VPU acknowledges them each. But after the last packet sent from the ICC the bus on the HEAD remains low. I think that’s the reason why the Acknowledge from the Head does not get to the ICC and the bus keeps blocked.
I would expect here an ACK followed by a stop condition, so the bus could be free on the VPU and the head.

After 300 ms the bus gets Free again like this.

That's what I expect to see there instead.

A test without the levelshifter is running.
We're using the LSF0204 at the moment.

Best,

Christian

0 Zoe Bison over 2 years ago in reply to Christian Brey

TI__Mastermind 23685 points

Hi Christian,

Thank you for sharing the additional scopes. Let me look over these and see what may be occurring.

Is there more than one DS90UB953A and DS90UB954 experiencing this issue? If so, how many devices are experiencing this issue?

Best,

Zoe

0 Christian Brey over 2 years ago in reply to Zoe Bison

Prodigy 170 points

Hi Zoe,

there are multiple DS90UB953 and DS90UB954 in our devices and we have this issue with all of them in multiple devices.

Best,
Christian

0 Zoe Bison over 2 years ago in reply to Christian Brey

TI__Mastermind 23685 points

Hi Christian,

Would you be able to provide the I2C transactions that are being executed in these scope shots? Additionally, if you have a logic analyzer to use to measure these signals this could be helpful to clear up what transactions are being seen on the line.

What is the HEAD referring to in regards to the block diagram? Is the HEAD, the output I2C line from the serializer? From my understanding the VPU is pertaining to the I2C bus between the processor and the deserializer. As mentioned in your response, I wouldn't expect the HEAD line to continue the I2C transaction without the additional information from the VPU.

Best,

Zoe

0 Christian Brey over 2 years ago in reply to Zoe Bison

Prodigy 170 points

Hi Zoe,

I'll have a look for an logic analyser but till then, here is the principle of the latest communication I sent:

VPU adressees ICC -> ICC answers with his status registers

after each byte there is an acknowledge from the VPU which is sent up to the ICC which is triggers by the ACK to send his next byte. When the VPU has all the data it sends an NACK to tell the ICC that it has sent all the data followed by a stop condition.

0 Christian Brey over 2 years ago in reply to Christian Brey

Prodigy 170 points

figure 1
HEAD	0xA3	Ack 0x26	ACK 0x16
VPU	0xC1	ACK 0x26 ACK	0x16 ACK


figure 2
Head	ACK 0x55	ACK 0x00	ACK 0x00	ACK 0x80
VPU	0x55 ACK	0x00 ACK	0x00 ACK	0x80 ACK


figure 3
Head	NACK STOP
VPU	0xFF ACK	0xFF ACK	0xFF ACK	0xFF ACK	0xFF ACK	0xFF ACK	0xFF ACK	0xFF ACK	0xFF ACK


figure 3
Head	0xA3	ACK 0x04	ACK 0x19	ACK 0x55	ACK 0x1D	NACK STOP
VPU		0x04 ACK	0x19 ACK	0x55 ACK	0x1D NACK STOP

0 Zoe Bison over 2 years ago in reply to Christian Brey

TI__Mastermind 23685 points

Hi Christian,

Thank you for sharing. To verify other devices aren't sending spurious transactions, the devices should be depopulated and populated one by one.

Additionally, the watchdog timer from the serializer was set to 1 second in the initial register dumps provided. In the most recent datasheet update, we recommend a value of 0x12 in register 0xA to decrease the I2C watchdog timer to 50ms. The I2C transaction in figure 2 could then be missing a response from the target address, leaving the line low as more data is expected.

Best,

Zoe

0 Christian Brey over 1 year ago in reply to Zoe Bison

Prodigy 170 points

Hi Zoe,

I did some more investigations I like to share with you. As you recommended, I took all the devices from the bus and communicated with them seperately, without any trouble. When I connected the first device on the bus again and tried to communicate with it (write and/or read commands in an endless loop) there where some errors no matter which device I used. The errors where always missed stop conditions or ACK/NACK bits. This picture shows the pauses in communication of abot 300 ms.

What I could see as well, was that the communication only got in error states during modulation of the illumination. The I2C signals itself are not influenced by the transients as well as all the suply voltages are looking good.
Nevertheless there are communication errors on the FPD-link channel I2C.

Best,

Christian

0 Zoe Bison over 1 year ago in reply to Christian Brey

TI__Mastermind 23685 points

Hi Christian,

Thank you for the update. Since back channel errors were seen by the system, would you be able to run MAP tool and BIST on the 954 to check the link margin with the 953? Additionally, can you provide a schematic for the 954 and 953?

Best,

Zoe

0 Christian Brey over 1 year ago in reply to Zoe Bison

Prodigy 170 points

Hi Zoe,

how can I run the MAP tool on the 954 on our Device? Otherwise it would be difficult to have the exact same setup running and what do you mean by BIST?

Is this the scematic you were asking for or what exactly do you mean?

Best,

Christian

0 Zoe Bison over 1 year ago in reply to Christian Brey

TI__Mastermind 23685 points

Hi Christian,

Christian Brey said:
how can I run the MAP tool on the 954 on our Device?

MAP tool would be set up by using the Analog LaunchPAD GUI and connecting a USB2ANY to the I2C inputs of the 954. MAP tool can then be used within the GUI to observe the link quality between the 954 and 953. If this access to the I2C input is possible, the setup will not need to change. BIST is a feature on the 954 for at-speed built-in self test. The 954 will send register writes to the 953 to configure BIST mode. The deserializer will then monitor for the test pattern and report any errors that are seen. A BIST script is also available in the GUI when navigating to Scripting -> Run predefined script -> 953_954_BIST.

Christian Brey said:
Is this the scematic you were asking for or what exactly do you mean?

Regarding a schematic, I was looking for the implementation of the 954 on the VPU board and 953 on the Main board.

Best,

Zoe

Interface

Interface forum

DS90UB953A-Q1: Missing stop bit at i2c with DS90UB953 and DS90UB954