Post Go back to editing

VBUS load >10 mA during discovery causes Line Fault 0x9 (short) error

Category: Hardware
Product Number: AD2437

Feel like I'm missing something obvious on this one...

As part of a test setup for AD2437 system a 100 ohm load can be jumpered in to a node to simulate the actual application.  With nominal VBus of 24V that's 240 mA and datasheet says 250 mA is the max allowed during discovery.

After some trial and error it seems like a VBUS load of > 10 mA (+/- a few mA) is enough to fault the discovery.  Once discovery complete there's no issue with the 100 ohm (240 mA) load being connected.  The node has a 100uF cap on the VBUS.<--- see reply that clarifies this and provides additional info

This is being run from SS+ 2.2.0 with 1.3.2 A2B plugin, the node is CFG4 RJ45 powered and SS+ is set to this.

I've tried this on multiple different sub nodes in different positions in the chain and issue seems consistent.  I don't see any register(s) that set the startup current limit during discovery nor a way to read what the AD2437 thinks the current was?  I tried enabling retries but that didn't change anything.



add note about 100uF cap
[edited by: Brewster at 1:43 PM (GMT -4) on 30 Sep 2024]
  • I take back what I wrote about being able to add loads after discovery.  The initial testing configuration had all the boards connected to a common ground via an external supply. That supply wasn't actually being used for this test so it was removed, which now means that instead of a common ground there are separate grounds for each group of 4 nodes (as the test fixture supports 4 boards at a time).

    Without the common ground adding a 4th load (i.e. approx 1A total) causes a "Bus Drop" though not at any of the nodes with the VBUS loads, it seems to claim the 4th node is where the problem is and the nodes with loads are at >9.

    This is a CFG4 system so there's no sensing of the VBUS return. 

    I'm going to make a guess that the process of attaching the load create enough corrupted bus traffic due to the sudden impedance shift in ground? (but exactly how? the bus to ground connection has 3.3 uH chokes as part of the 5V that's sent over the A2B pair).  It's consistent though that it is always the 4th load added regardless of position, I would expect if it really was bus data corruption then adding any load would cause a failure.

    if data corruption was the cause then why is it OK do add loads when there's the common ground configuration?

    How can I get more diagnostics about why the Bus Drop is being reported and/or is there a way to increase the tolerance before it start auto-discovery again?

  • Detail of the set up.  This maybe will  help understand the specific setup in this test. All nodes are AD2437 and the 100 ohm VBUS loads are being added from the end and working backwards (i.e. quad boards 4 and 3):

    Evm (main) -> A2B isolater -> 6' CAT 6 -> Quad board 1 -> 100’ Cat6 -> Quad board 2 -> 50’ Cat 7 -> Quad board 3 -> 50’ Cat7 -> Quad board 4 (3 positions filled)

  • Continuing to look at this:
    The same thing happens if I start with all the boards grounded, add the resistors, and then start breaking the ground connections between the boards.  I could believe a change in ground might be corrupting A2B traffic but seems improbable that it would cause a system failure in a CFG4 RJ45 system?

    I had set up a scope on the subnode reporting the drop to capture A2B at port B but nothing odd shows up around where the upstream is lost. (cyan trace is FSYNC from the next downstream node from the one reporting the drop).

  • Trying to see if I can find anything that works...I reduced the node count to 7 on the off chance having more that 10 nodes had something to do with.

    No difference, a single 240 mA load gets called a short, and adding loads once discovery completes fails when the 4th one is added.

  • VBUS Bulk cap:
    Looking back I think the topic of bulk cap on VBus isn't clear from available documentation.  In CFG0 bus powered nodes could not have a large capacitance on them as it would trip the current sense/short detect on startup.  The AD2437 documentation implies this is also the case for CFG4 power, though on a re-read I am no longer sure what the correct design is for bus powered nodes and a check of the latest docs did not show any further clarification.

    As an experiment, I added 47uF to each node of the 7 node configuration.  This produced discovery faults regardless of the presence or not of the 100 ohm (240 mA) load.  Swapping around nodes without the 47uF sometimes discovery might proceed a little bit further but it would appear that the old rules about bus powered nodes and VBus capacitance still apply?  Or perhaps I need "some" capacitance?

    Perhaps there's some HW design error I've made vs. thinking this was a software related issue?  Here's the relevant schematic snips, I think I copied the ref design correctly...

    The VBUS input (A port) has 10uF on it and a small DC/DC that produces 5V used in this part of the circuit.  (The hierarchy in the Altium schematic is because this is a module and multiple A2B sections exist in some versions, though the one here is just a single A2B)

    Is 10uF not enough on the VBUS input?  Too much?  Could the startup characteristics of the DC/DC trip the discovery sequence?

  • Using 8 sub-nodes with 47 uF caps on all bus powered nodes and 100uF at the local powered node seems to start up correctly about 90% of the time.  It occasionally says it has found a short out around the 5-7th nodes.  But it also sometimes dies at the main node and this seems to be a USBi bug as disconnecting USBi are plugging in again seems to clear it.  So I think maybe having caps at bus powered nodes is OK in CFG4 land but not allowed with CFG0? 
    I can not find any documentation that clarifies what the right cap values for CFG4 bus powered nodes might be.

    Adding one load resistor (8th sub-node/last node) causes network load to fail with 0x9 error.  This is with Vbus reduced to 12V so the load is only 120 mA vs. 240 mA with 24V.  Here's three link/compile/download sequences current vs. time.  The meter only captures at 10 msec rate and their (Siglent) plotting isn't great so probably missing some detail. The first time the failure is reported at the 6th sub node and the other to at the 7th node.

    Here's three times with no 120 mA load at the 8th subnode.

    I'm thinking the sampling rate is too slow to see whatever current spike the last node is creating.

    However I can add 7 loads and it keeps running, so it would appear the caps are helpful in dealing with the transients that are happening when I jumper in each load resistor.  here's a plot of the total current as I'm adding jumpers (with 12V Vbus):

    The million $ question remains:

    Why won't the system startup when the loads are present?  Hardware design error?  Register setting?  Software bug?

  • On the off chance that the AD2437 seeing a large load on VBus during discovery was creating a problem switched over to doing the 2 step discovery (RJ45). This did not change anything, still get 0x9 fault if the 100 ohm (200 mA as lowered VBus in case 240 mA was too close to the 250 mA limit).  Attached a trace - I as looking at that in hope of finding a hint as to why the 2437 thinks there's a short.

    a2b_trace.txt

    So far I have not been able to find what the AD2437 is looking for to decide there's a fault.  The high limit bit in SWSTAT2 is not set.

    As a second experiment I add 100 ohms to a EVAL-AD2437B1NZ (XLR bus powered node, don't have the MZ RJ45 one) 24V and it doesn't cause an error.  While there's some differences between the CFG4 RJ45 and XLR I would expect the same results.

    The eval board has 660 uF on the 24V (still looking for some explanation of what CFG4 expects, since CFG0 would fault with more than a few uF).  Add 470 uF to my boards but no change, network (4 sub nodes) runs fine with no 100 ohm on the 24V but errors out with 0x9 if the load is present.

    I even tried setting the power type to XLR in SS+ since it seems like the AD2437 really can't tell the difference.

    The fact that the XLR works and RJ45 is failing kind of points to a hardware issue?  I looked through discovery.c and don't see where RJ45 vs. XLR makes a difference to fault detection.

    It would help if the AD2437 was documented for how it performs the first part of line diagnostics for discovery. In the meantime will look in more detail what mine's doing vs. the EVAL-AD2437B1NZ.

    Still thinking I've overlooked something obvious.

  • And the answer is:

    Set A2B_SWCTL.MODE = 2.

    Based on the (limited) available information this should have nothing to do with any of this.  Yet it solves it - will create a separate issue to find out why, and what better solutions may exist.