Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

FPC402EVM: Downstream I2C access is not acknowledged by FPC402

Part Number: FPC402EVM
Other Parts Discussed in Thread: FPC402, FPC401
We are using FPC402EVM. We are accessing the FPC402 via external host and are able to communicate with FPC402 via default address 0x1E. We are able to control the GPIOs and the other I/Os of the FPC402 (like turn ON LED etc)
We have only one FPC402 at address 0x1E. So as per table 6 in datasheet, the address for down stream I2C port0 is 0xF0.
We issue a read access to device 0xF0 after necessary init of the GPIOs and I/Os (enable VCC to the QSFP/SFP module), De activate the RESET_L to the module etc.
We have verified that the power to the modules are good. The modules are out of reset etc.
Is there any reason why the ACK is not received at the host for access to 0xF0 ? As mentioned earlier, there is only one FPC and it is working with default address 0x1E. Register values at the FPC402 are dumped below.

Value@0x00: 0xf 

Value@0x01: 0x3f 

Value@0x02: 0x0 

Value@0x03: 0x11 

Value@0x04: 0x6 

Value@0x05: 0x1c 

Value@0x06: 0xb0 

Value@0x07: 0xf8 

Value@0x08: 0xff 

Value@0x09: 0xff 

Value@0x0a: 0xff 

Value@0x0b: 0xff 

Value@0x0c: 0x0 

Value@0x0d: 0x0 

Value@0x0e: 0x1 

Value@0x0f: 0xef 

Value@0x10: 0x11 

Value@0x11: 0x98 

Value@0x12: 0x98 

Value@0x13: 0x4 

Value@0x14: 0x0 

Value@0x15: 0x0 

Value@0x16: 0x0 

Value@0x17: 0x0 

Value@0x18: 0x0 

Value@0x19: 0x0 

Value@0x1a: 0x30 

Value@0x1b: 0x0 

Value@0x1c: 0x0 

Value@0x1d: 0x0 

Value@0x1e: 0x0 

Value@0x1f: 0x0 

Value@0x20: 0x0 

Value@0x21: 0x80 

Value@0x22: 0x0 

Value@0x23: 0x0 

Value@0x24: 0x0 

Value@0x25: 0x0 

Value@0x26: 0x0 

Value@0x27: 0x0 

Value@0x28: 0x0 

Value@0x29: 0x0 

Value@0x2a: 0x0 

Value@0x2b: 0x0 

Value@0x2c: 0x0 

Value@0x2d: 0x0 

Value@0x2e: 0x0 

Value@0x2f: 0x0 

Value@0x30: 0x11 

Value@0x31: 0x98 

Value@0x32: 0x98 

Value@0x33: 0x4 

Value@0x34: 0x0 

Value@0x35: 0x0 

Value@0x36: 0x0 

Value@0x37: 0x0 

Value@0x38: 0x0 

Value@0x39: 0x0 

Value@0x3a: 0x30 

Value@0x3b: 0x0 

Value@0x3c: 0x0 

Value@0x3d: 0x0 

Value@0x3e: 0x0 

Value@0x3f: 0x0 

Value@0x40: 0x0 

Value@0x41: 0x80 

Value@0x42: 0x0 

Value@0x43: 0x0 

Value@0x44: 0x0 

Value@0x45: 0x0 

Value@0x46: 0x0 

Value@0x47: 0x0 

Value@0x48: 0x0 

Value@0x49: 0x0 

Value@0x4a: 0x0 

Value@0x4b: 0x0 

Value@0x4c: 0x0 

Value@0x4d: 0x0 

Value@0x4e: 0x0 

Value@0x4f: 0x0 

Value@0x50: 0x11 

Value@0x51: 0x98 

Value@0x52: 0x98 

Value@0x53: 0x4 

Value@0x54: 0x0 

Value@0x55: 0x0 

Value@0x56: 0x0 

Value@0x57: 0x0 

Value@0x58: 0x0 

Value@0x59: 0x0 

Value@0x5a: 0x30 

Value@0x5b: 0x0 

Value@0x5c: 0x0 

Value@0x5d: 0x0 

Value@0x5e: 0x0 

Value@0x5f: 0x0 

Value@0x60: 0x0 

Value@0x61: 0x80 

Value@0x62: 0x0 

Value@0x63: 0x0 

Value@0x64: 0x0 

Value@0x65: 0x0 

Value@0x66: 0x0 

Value@0x67: 0x0 

Value@0x68: 0x0 

Value@0x69: 0x0 

Value@0x6a: 0x0 

Value@0x6b: 0x0 

Value@0x6c: 0x0 

Value@0x6d: 0x0 

Value@0x6e: 0x0 

Value@0x6f: 0x0 

Value@0x70: 0x11 

Value@0x71: 0x98 

Value@0x72: 0x98 

Value@0x73: 0x0 

Value@0x74: 0x0 

Value@0x75: 0x0 

Value@0x76: 0x0 

Value@0x77: 0x0 

Value@0x78: 0x0 

Value@0x79: 0x0 

Value@0x7a: 0x30 

Value@0x7b: 0x0 

Value@0x7c: 0x0 

Value@0x7d: 0x0 

Value@0x7e: 0x0 

Value@0x7f: 0x0 

Value@0x80: 0x0 

Value@0x81: 0x80 

Value@0x82: 0x0 

Value@0x83: 0x0 

Value@0x84: 0x0 

Value@0x85: 0x0 

Value@0x86: 0x0 

Value@0x87: 0x0 

Value@0x88: 0x0 

Value@0x89: 0x0 

Value@0x8a: 0x0 

Value@0x8b: 0x0 

Value@0x8c: 0x0 

Value@0x8d: 0x0 

Value@0x8e: 0x0 

Value@0x8f: 0x0 

Value@0x90: 0x0 

Value@0x91: 0x0 

Value@0x92: 0x0 

Value@0x93: 0x0 

Value@0x94: 0x0 

Value@0x95: 0xf0 

Value@0x96: 0x22 

Value@0x97: 0x0 

Value@0x98: 0x0 

Value@0x99: 0x0 

Value@0x9a: 0xff 

Value@0x9b: 0x0 

Value@0x9c: 0x0 

Value@0x9d: 0x5 

Value@0x9e: 0x5 

Value@0x9f: 0x5 

Value@0xa0: 0x5 

Value@0xa1: 0xff 

Value@0xa2: 0xff 

Value@0xa3: 0xff 

Value@0xa4: 0xff 

Value@0xa5: 0x0 

Value@0xa6: 0x0 

Value@0xa7: 0x0 

Value@0xa8: 0x0 

Value@0xa9: 0xff 

Value@0xaa: 0xff 

Value@0xab: 0xff 

Value@0xac: 0xff 

Value@0xad: 0x0 

Value@0xae: 0x0 

Value@0xaf: 0x0 

Value@0xb0: 0x0 

Value@0xb1: 0x0 

Value@0xb2: 0x0 

Value@0xb3: 0x0 

Value@0xb4: 0x50 

Value@0xb5: 0x51 

Value@0xb6: 0x50 

Value@0xb7: 0x51 

Value@0xb8: 0x50 

Value@0xb9: 0x51 

Value@0xba: 0x50 

Value@0xbb: 0x51 

Value@0xbc: 0x0 

Value@0xbd: 0x0 

Value@0xbe: 0x0 

Value@0xbf: 0x0 

Value@0xc0: 0x0 

Value@0xc1: 0x0 

Value@0xc2: 0x0 

Value@0xc3: 0x0 

Value@0xc4: 0x0 

Value@0xc5: 0x0 

Value@0xc6: 0x0 

Value@0xc7: 0x0 

Value@0xc8: 0x0 

Value@0xc9: 0x0 

Value@0xca: 0x0 

Value@0xcb: 0x0 

Value@0xcc: 0x0 

Value@0xcd: 0x0 

Value@0xce: 0x0 

Value@0xcf: 0x0 

Value@0xd0: 0x0 

Value@0xd1: 0x0 

Value@0xd2: 0x0 

Value@0xd3: 0x0 

Value@0xd4: 0x0 

Value@0xd5: 0x0 

Value@0xd6: 0x0 

Value@0xd7: 0x0 

Value@0xd8: 0x0 

Value@0xd9: 0x0 

Value@0xda: 0x0 

Value@0xdb: 0x0 

Value@0xdc: 0x0 

Value@0xdd: 0x0 

Value@0xde: 0x0 

Value@0xdf: 0x0 

Value@0xe0: 0x0 

Value@0xe1: 0x0 

Value@0xe2: 0x0 

Value@0xe3: 0x0 

Value@0xe4: 0x0 

Value@0xe5: 0x0 

Value@0xe6: 0x0 

Value@0xe7: 0x0 

Value@0xe8: 0x0 

Value@0xe9: 0x0 

Value@0xea: 0x0 

Value@0xeb: 0x0 

Value@0xec: 0x0 

Value@0xed: 0x0 

Value@0xee: 0x0 

Value@0xef: 0x0 

Value@0xf0: 0x10 

Value@0xf1: 0xa0 

Value@0xf2: 0x0 

Value@0xf3: 0x0 

Value@0xf4: 0x0 

Value@0xf5: 0x0 

Value@0xf6: 0x0 

Value@0xf7: 0x0 

Value@0xf8: 0x0 

Value@0xf9: 0x0 

Value@0xfa: 0x0 

Value@0xfb: 0x0 

Value@0xfc: 0x0 

Value@0xfd: 0x0 

Value@0xfe: 0x0
  • Hi Bala,

    For the read operation you're issuing to the module, does the target register address fall in the prefetch range of the FPC402?

    In any case the host must either see an ACK or a NACK depending on whether the module is present or absent at the device address 0xF0. Could you probe the downstream I2C lines and see the communication to and from the module to the FPC402 port, while the host performs the read operation?

    Thanks,
    Sri
  • The data sheet mentions that 0xF0 is the address that is mapped for port P0 when the FPC device address is 0x1E. So My understanding is that, we are accessing the correct address.

    As per documentation, my understanding is that the FPC device shall ACK the host for access to address 0xF0, even before polling the Port0 I2C down stream port.. Is it not the case ?

    In our case, we do have QSFP/SFP+ modules present and as I mentioned, they are powered as well as out of reset etc ..

    As I said before, we are able to access all the internal registers of the FPC device with device address 0x1E. Please see the register dump

  • Hi Bala,

    I meant the register offset which you are trying to read- does that fall within the prefetched range of the FPC402? Just wanted to understand if the FPC is reading from local registers or the module. I agree 0xF0 should be the correct address and you should see ACK to the host in both the cases.

    Once the FPC402 receives a read command, it first checks with the device ID through the corresponding downstream I2C port and send back either ACK or NACK to the Host depending on whether the module is present or absent (In this case it should receive an ACK from the module which it should have sent to the Host). So I was just curious to know if you see any communication on the downstream port during this read operation..

    Thanks,
    Sri
  • I think the prefetch is disabled (by default ?).
    Will check with the scope and post the info
  • Hello Sri

    Do you see any issue with any register programming ? The register dump is available in the initial post

    Thanks

    Bala

  • Hi Bala,

    Looks like you have configured the Register 0xB4 which specifies the address for Port 0, Device 0 to the default value of 0x50 (corresponding to the 8-bit address of 0xA0). That is why the device is not responding to the 0xF0 address. Table 6 just lists all the possible valid I2C addresses that may be assigned to the devices. However, the default address for the device 0 of any port will be 0xA0 unless and until reconfigured using this register 0xB4. Please see section 2.70 of the programming guide for instructions on how to configure the port 0 device 0 ID to your target address.

    Thanks,

    Sri

  • Hello Sri
    We have only FPC401 Programmers guide (SNLU221A - Dec 2016, revised 2017). I had requested documentation for FPC402 four days back. I have also provided the TI team with all the data regardng the project (build schedule , project name, annual usage etc). Looks like access has not been granted. Could you please see what is happening ?
    Please provide us with latest data sheet for FPC402 and its programming guide.
    Looks like we are using the wrong programming guide. FPC401 programming guide do not have section 2.7 or description for register 0xB4
    Thanks
    Bala
  • Hi Bala,

    Sorry for the delay on your request. I've just granted you access to the FPC402 documentation including the full confidential datasheet, programming guide, SDK and EVM userguide. Except for the sections related to the I2C addressing of the device and ports, everything else should be the same as that of the FPC401 that you have been using, so you don't need to change the registers too much.

    Please go through the Section 2.70 in the FPC402 program guide and configure the desired address for port 0 device 0 accordingly.

    Thanks,
    Sri
  • Hello Sri,
    Thanks for granting the access. I will check this out. But below is my thought -
    The default value for register 0xB4 and other similar registers for Port1,Port2,Port3 should be fine if it is 0x50. The reason being, these are the addresses, the FPC402 will use for down stream access when the access from the upstream happens to address 0xF0.
    For example,
    if upstream access happen to 0xF0, then FPC402 will initiate a down stream access of device address 0xA0 on port0.
    if upstream access happen to 0xF4, then FPC402 will initiate a down stream access of device address 0xA0 on port1. .. and so on

    So where else are we going wrong ?

    Also, can you please grant /approve the account creation for my colleague Manju Mahajan (email : manju.mahajan@fungible.com).
    She has submitted profile info and waiting for activation.
    Thanks
    Bala
  • Bala,

    I'm not sure I understand your example. As long as the Register 0xB4 is not reconfigured, the device 0 needs to be accessed by its default address 0xA0. Please try to access through 0xA0 in your current configuration of the registers and let me know if you see the ACK signal or not. Alternatively, you may try updating register 0xB4 to correspond to 0xF0 (following Section 2.70 in programming guide) and try accessing using that. Let me know if it resolves the issue.

    Sure, I have granted her the access to the folder now.

    Thanks,
    Sri
  • Hello Sri,
    Finally we cracked it.
    Reset Register (Offset = 0x00) bits [3:0] had to be written with 0xf and then 0x0 to reset the port state machines, before it started working.
    Now we are able to read down stream QSFP and SFP modules.
    I think, this info is not explicitly documented.
    Thanks
    Bala
    Re
  • Hi Bala,

    Wonderful news! The programmer guide specifies the default value for this register to be 00, but yes it does not explicitly state that it has to be reset back to this value for accessing the downstream ports.  

    Thank you for sharing the info, will look into updating the documentation with our team.

    Regards,

    Sri