BQ79600EVM: NFAULT not asserted when daisy chain gets disconnected?

Julian,

Typically we would expect a communication timeout to trigger the fault flag, however when using the GUI, we disable the communication timeout for ease of use.

Hi Alexander,

I do not use the GUI at the moment. And I have verified that the COMM_TIMEOUT register is set to its reset value of 0x34 (10s/1m). Nevertheless, no NFAULT assertion... Any ideas?

Julian,

Have you enabled the heartbeat tone?

Because data communication is not available in SLEEP mode, the device provides following options to transmitting fault information:

1) transmit the Heartbeat tone (enabled by [HB_TX_EN], used to check integrity of cable between bridge and first stack device). Device does not transmitted fault tone as it has NFAULT.

 2) detect Heartbeat and Fault tone, enabled, by [TONE_RX_EN]

These tones are transmitted in the same direction as a communication command frame, which is based on the CONTROL1[DIR_SEL] setting. For the tone signal to return back to BQ79600-Q1 (so NFAULT can be triggered if needed), a Ring architecture must be used to support transmitting fault status in SLEEP mode.

Take a look at the BQ79600-Q1 datasheet section 7.3.3.2 Fault Interface for more information

Note on my setup: Ring as in EVM manual: 600H <---> #1 L616H <---> #2 L616H <---> L600

Thanks. These bits do configure the HB in sleep according to the datasheet. I have not used the SLEEP mode yet. I wake the system up, configure it and aquire data every second.

However, enabling HB_TX_EN and TONE_RX_EN at the bridge and HB_EN, FTONE_EN at the stack has kind of inverted the issue :). I now get a persistent FAULT_COMM1[HB_FAIL] at the bridge (stack is error free). When I reset that every second, I end up with short fault LED flashes. The good news: When I unplug something in the daisy chain, I get long flashes -> I get a reaction that I was missing before. But that still raises questions.

1.) The behavior seems to contradict the datasheet description: I do not use sleep and I would have expected an open wire in the daisy chain to trigger an NFAULT. But I seem to be required to set the bits that you have suggested to get a reaction. Why?

2.) What could trigger the HB_FAIL at the bridge? I could only imagine open daisy chain or stacks having HB_EN, FTONE_EN disabled. But I verified that these possible causes are not the culprit.

BRIDGE
  CONTROL1
    ADDR_WR         0
    SOFT_RESET      0
    GOTO_SLEEP      0
    GOTO_SHUTDOWN   0
    SEND_SLPTOACT   0
    SEND_WAKE       0
    SEND_SHUTDOWN   0
    DIR_SEL         0


BRIDGE
  DEV_CONF1
    HB_TX_EN        1
    SEL_TX_TONE     0
    NFAULT_EN       1
    TWO_STOP_EN     0
    FCOMM_EN        1
    TONE_RX_EN      1
    SNIFDET_DIS     0
    SNIFDET_EN      0

STACK #1
  DEV_CONF
    HB_EN           1
    FTONE_EN        1
    NFAULT_EN       1
    TWO_STOP_EN     0
    FCOMM_EN        1
    MULTIDROP_EN    0
    NO_ADJ_CB       1

STACK #2
  DEV_CONF
    HB_EN          1
    FTONE_EN       1
    NFAULT_EN      1
    TWO_STOP_EN    0
    FCOMM_EN       1
    MULTIDROP_EN   0
    NO_ADJ_CB      1

To add a summary:

  - I would expect NFAULT to become active as long as the COMM_TIMEOUT is set, NFAULT_EN
  is set, no faults are masked and I disconnect something in the daisy chain for longer than the configured timeouts -> It does not. What could cause this?

- Monitoring for broken wires in the daisy chain while in SLEEP is configured by heart beat and fault tone settings. Enabling these results in a persistent HB fault even though I do not use the SLEEP mode yet. Why does it trigger when not even in SLEEP mode?

Julian,

The HB_TX_EN heartbeat tone is the method that the BQ79600 device uses to determine if the daisy chain is broken. Typically in active mode, the MCU should be doing a manual communication check so we usually don't need to enable the heartbeat to know if there is a break. I had you turn the heartbeat tone on in active mode which caused the fault to trigger in your case (see below text from the datasheet). I hope this makes more sense now?　

9.3.6.2.3.3 Heartbeat and Fault Tone　

The tones are enabled by setting DEV_CONF[HB_EN] = 1 and DEV_CONF[FTONE_EN] = 1 to enable the Heartbeat and Fault Tone transmitters, respectively. The Heartbeat and Fault Tone receivers are always on in SLEEP mode regardless of the [HB_EN] and [FTONE_EN] settings. To avoid fault detection (asserting NFAULT or FAULT_SUMMARY register) by Heartbeat or Fault Tone fault, mask the fault by [MSK_COMM3_HB] = 1 or [MSK_COMM3_FTONE] = 1.

The Heartbeat and Fault Tone are formed with couplets with "–" polarity. They are differentiated by the number of couplets. Unlike communication tones, Heartbeat and Fault Tone are transmitted periodically. The period between tones is referring as Burst period. The number of couplets transmitted is always greater than the number of couplets needed for detection.

Ok, I think I get it now. I am required to enable TONE_RX_EN _only after_ I sent all stack devices (with HB enabled) to sleep, right? I thought enabling TONE_RX_EN would only take effect when the stack is in SLEEP. So the sequence would be: Enable HB and FT for stack -> enable HB TX for Bridge -> send stack to SLEEP -> enable FT and HB detection at bridge (TONE_RX_EN). Have not tried yet but this could be it. If that is the case, that sequence should really be mentioned in the datasheet.

But still: Why won´t I get a comms fault despite COMM_TIMEOUT being properly configured? This was my issue in the first place. And as mentioned, I do not use the GUI. I am working with my own driver. I would have expected the comms fault bit to trigger which in turn would activate NFAULT. Isn´t that how it is supposed to be?

Julian,

The communication timeouts are used to transition the device into shutdown mode. They don't trigger the NFAULT pin

Communication timeout: automatically transitions from ACTIVE mode to SHUTDOWN mode if there is no valid communication for the configured time. Host can enable this option through the COMM_TIMEOUT_CONF register.

SLEEP mode timeout: automatically transitions from SLEEP mode to SHUTDOWN mode if device is in SLEEP mode for the configured time. Host can enable this option through PWR_TRANSIT_CONF[SLP_TIME2:0].