Bus Reset Propagation in high-frequency Bus Resets

  • Background

    Implementing the solution for the Legacy Loop Detect patent revealed that in a mixed environment (nodes with and without the enhancement) high frequency Bus Resets generated by a single node cause dramatic device disconnects.


    • Node_A generates Bus Reset causing all other nodes to start initialization

    • If Node_A generates 3 more Bus Resets before node finish (i.e. transitions into S1:Self-ID Grant or S2 Self-ID Receive):
      • nodes’ resetCount will be greater than 3 causing disconnect from neighboring nodes
      • Worsened by TI PHY’s incorrect implementation: PHYs do not clear resetCount until transition into A0 (normal arbitration)
      • Results in much larger time window for resetCount>0 to happen
  • Analysis

    Testing results

    Scenario: Nodes A, B, C and D are connected in a single topology.

    Node C’s resetCount variable will become greater than three (3) and consequently will cause Node C to disconnect from Node B thus temporarily creating two separate node topologies (Nodes A and B, Nodes C and D) if:

    • Node A generates four (4) consecutive bus resets
    • Resets are spaced close enough together that Node C doesn’t transition to S1: Self-ID Grant or S2: Self-ID Receive state between bus resets

    ... and to make things worse:

    It should be noted that Texas Instruments (TI) TSB41BA3 and TSB81BA3 PHYs do not behave exactly as the IEEE-1394 standard defines.  In fact, it appears these PHYs do not clear the resetCount variable until the PHY transitions from the Self-id to normal arbitration state A0. This creates, especially in large topologies, a much larger timing window in which four (4) consecutive bus resets could cause resetCount to be greater than three (3) and cause a port to disconnect.

  • Innovation

    A Node shall test each connected port of its PHY and if a bus reset is detected, portRArb[i] == BUS_RESET, and busInitializeActive, the PHY is currently in a bus initialize state (R1|T0|T1|T2|T3|S0|S1|S2|S3|S4), the PHY will block the propagation, repeat_Bus_Reset = FALSE, the received bus reset to its other active ports. The PHY port receiving the bus reset responds with bus reset, return_Bus_Reset[i] = TRUE. When the other ports transition out of a bus initialize state, busInitializeActive = FALSE, the received bus reset is then repeated to its other active ports, repeat_Bus_Reset = TRUE.

    This behavior was designed into the IEEE-1394-2008 standard to detect a loop between Alpha nodes during bus initialization as described in the IEEE-1394-2008 section “14.7.13 Loop detection during bus initialization”:

    Some loop conditions may be detected during bus initialization. They are:

    1. Configuration timeout (in the T0: Tree ID Start state), which can occur if the node is on a loop and either that loop includes one or more Alpha nodes or the loop is formed as a result of a connection on the bus being resumed.
    2. Arbitration state timeout, which can occur up to the time when the port enters the S1: Self-ID Grant or S2: Self-ID Receive state if the node is connected to a network of Alpha nodes that are in a loop.
    3. Repeated resets, which can occur in similar circumstances to condition b with a loop on a network that includes IEEE 1394 nodes that use a shorter arbitration state timeout.”

    In most cases this functionality is desirable. Also, some applications can guarantee either Alpha nodes are not preset, Beta nodes only, or Alpha nodes cannot be connected in a loop. Furthermore, in some environments, it is possible that bus resets can be generated quickly enough to cause a Beta node PHY port to incorrectly disable a connection between two different nodes for reasons other than a loop between Alpha nodes.


    User-configurable setting(s) to allow to adjust the settings for more robust bus operation during frequent bus resets.

  • Patent

    Patent: Blocking Bus Reset Propagation

    Title: Method for Blocking Bus resets in a IEEE-1394 High-performance Serial Bus

    Number:  US9,747,186

    Assignee: DapHolding B.V. (parent company of DapTechnology B.V.)

    FilingDate:  2014-12-29

    GrantDate: 2017-08-29


    A method of delaying or blocking new bus resets from propagating while a previous bus initialization (bus reset, tree-id or self-id) is in process during the performance of a IEEE-1394 serial bus. The bus resets are caused by noise events, power-up and power-down sequences and other bus reset causing events.

    The method provides for more robust Beta only bus operation during high frequency bus resets.


    It is in DapTechnology's core interest to dive forward IEEE-1394 and AS5643 technologies. We invite all interested parties to engage into licensing discussions and ensure a more stable future for the technologies.