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.

BQ79600-Q1: FCOMM_DET

Part Number: BQ79600-Q1
Other Parts Discussed in Thread: BQ79616, USB2ANY

The Bridge_FAULT_COMM1 register is read to identify any problems with the comm frame (FCOMM_DET). This fault byte does not clear when the fault has been removed using the simulator, as confirmed using the logic analyzer. If the bridge faults are cleared periodically by writing to the Bridge_FAULT_RST register, the fault is not being identified when present. This makes it difficult to recover from any COMM faults. Am I missing something in the BQ79600 register setup?

Today morning (5/30/23), I tried the same thing with the USB2ANY, BQ79600 EVM and BQ79616. After initial measurements started, I unhooked the cable connecting the BQ79600 an the BQ79616. No faults were reported on the BQ monitor. Voltage readings just froze and stayed unchanging. FCOMM_DET bit was set. I reconnected the cable. Voltage readings resumed. But the FCOMM_DET bit stayed set, it did not auto clear. I have the fault generation in the firmware based off the status of the FCOMM_DET bit. How does this need to change?

I also powered off the BQ79600 and re-did the wakeup, auto address sequence and started polling from the BQ GUI. The FCOMM_DET bit stayed set. Why is this value persistent?

  • Hello Priya,

    Apologies for the delay! 

    Are you clearing the fault from the stacked and base device? If these are all not cleared, then the fault will not clear.

    Best Regards,

    Luis Hernandez Salomon

  • Luis-- If I call   WriteReg(0, Bridge_FAULT_RST, 0x22, 1, FRMWRT_SGL_W);    as part of the measurement cycle, the FCOMM_DET clears. However, clearing this fault repeatedly also does not identify the COMM fault when present.

    If the daisy chain cable has been removed and plugged in, what signals the need to clear this bit? If I reflash the firmware after fixing this fault, the FCOMM_DET bit still seems set. 

    When I try with the BQ GUI here is what I see:

    I used the command sequence to write a 0 both to FAULT_RST and FAULT_COMM1 and the FCOMM_DET bit is still displaying as set. Why is this? It's almost like the value is part of the NVM or something. Is this the case with the EVM setup at your end?

    Here is the field view of the FAULT_COMM1 register. Edited to note this is a read only register

  • Hello Priya,

    To clear the faults you actually need to write 1 to FAULT_RST, not 0. Can you try again by writing 1 instead.

    Best Regards,

    Luis Hernandez Salomon

  • Yes, I am writing a 1 to try reset the FCOMM_DET bit.

    I am not seeing a change in the fault status:

    I even tried writing 0xff to register 0x2030 and the FAULT_COMM1 register still reads 0x40.

  • Hi Priya,

    FCOMM_DET indicates the fault in the stack devices, can you please read the fault registers from the stack devices, if you have captured the logs from logic analyzer can you please share. 

    FCOMM_DET Indicates the fault status bit in comm frame is set by stack devices. At least a fault in stack devices happened. Only apply to non-bq79606
    family
    0: no fault
    1: fault

    Can you also try clearing the FCOMM_DET bit on the stack devices and then clear the bit in BQ79600.

    Regards,

    Ravi

  • BQClr06052023.csv

    Here are the reset commands to stack, bridge and the fault status registers. The stack appears to not have any comm faults. The bridge is stuck at the FCOMM_DET.

    I have attached logic analyzer logs collected using the BQ79600 EVM. I have highlighted the reset commands in yellow. Bridge fault status is uncleared, stack is not reporting COMM_FAULT.

  • BQClr06052023_3.csv

    Here is a log I collected with the daisy chain cable first connected, then disconnected. I sent the following command sequence after disconnecting the daisy chain cable (highlighted in yellow in the log file):

    I find that the bridge is not reporting faults from the logs. What bridge register will identify that the daisy chain is disconnected? The bridge fault status in the register map continues to display the following:

    I need clarity on setting up and reading the bridge registers. Is it possible to understand this today?

    Priya

  • Hi Priya,

    From the logs you shared, I see only TX commands from MCU, but I don't see the response data from BQ device. Also, the format you shared is csv, so what ever you highlighted is not  saved. If possible, please share the complete logic analyzer logs you have captured, also share what version of logic analyzer you are using.

    From the screenshot you shared it seems like bridge is reporting 'FCOMM_DET' (0x2104) when the daisy chain is disconnected.  Also the issue you are facing is when you connect back the daisy chain, the 'FCOMM_DET' bit is not cleared'. Correct me if my understanding is incorrect.

    Regards,

    Ravi

  • BQClr06052023_2104.xls.xlsx

    The logic analyzer is letting me save only the tx or rx log. Attached is the BQ response logs. Lines 1394 to 1400 is the BQ register 2104 response. I have unplugged the dasiy chain cable. Why is the logic analyzer response not showing FCOMM-DET as set? I expect fault byte 0x40, but the LA is saying no fault is reported. But under the register map, the fault status permanently displays FCOMM_DET. I appreciate your prompt response.

  • Hi Priya, 

    Nice meeting today. I'm closing this thread as this was addressed on the call. 

    Regards, 

    Arelis Guerrero