Neo Unresponsive After Breaker Trip

We are using a NEO on our climber. While testing, the breaker supplying power to the NEO tripped. At this point the NEO would not work. I wasn’t present at the time but I’m told the light on the Spark Max was blinking indicating that it didn’t have 12V power. USB wasn’t connected and 12V power was the only power supply present to the Spark Max. We power cycled the motor controller and it started working again.

Has anyone else encountered something like this?

We were/are considering swapping our CIMs out for NEOs on our swerve at our first event but if they aren’t robust against intermittent power drops then this would be a show stopper.

Our theory is that an internal cap is keeping the Spark Max alive while the breaker is tripping but the software state becomes invalid during this time. By killing power for a longer duration this forces a hard reset of the Spark Max.

1 Like

If you didn’t have USB connected, and the breaker tripped (preventing battery power from reaching the Spark), then how would the SparkMax have power to illuminate the LEDs to indicate “no 12V supply”…?

Doesn’t quite add up. Make sure the LED color/pattern was correct, and not “disabled”, or “no CAN”, etc.

I think @kylelanman meant that the breaker tripped and then reset. Presumably at some point within those few seconds, the SPARK MAX entered a “no 12V” mode potentially powered by a built-in capacitor. It then failed to exit that “no 12V” mode after power was restored.

We had a similar issue once or twice but thought it was a wiring issue. We rewired the SPARK MAXes and haven’t had the issue since. So we didn’t have reason to believe it was a problem with the MAX itself. EDIT: I should also note that at some point we had an issue where our chassis was shorted to Vbat so that could have been our issue as well. Now that’s fixed though.

I think one way to test if this is feasible is powering a SPARK MAX and then turning off the main breaker. Does it persist in a “no 12V” mode for a few seconds before turning off completely?

Edit 2: Dug up some slack messages. Here are some more details for our problem. We were getting output on only one of our two elevator SPARK MAXes, which was causing unreasonably high current draw. As a result we were tripping the breaker on just that SPARK MAX. After the power came back, it would get stuck in an uncommandable state (wouldn’t even show up on CAN bus). We rewired both and in the process found out that the Anderson on the white wire on the non-working SPARK MAX was improperly seated. Also found that our chassis was connected to Vbat via a few errant strands on the Vin crimp for the working SPARK MAX. Fixed this and now both worked, so we haven’t popped a breaker since and haven’t observed the problem.

Yes. It was an intermittent trip due to high current draw. The self resetting nature of the breaker reset itself.

Have you updated your SPARK MAXs to the latest firmware? In one of the last updates we adjusted how the controller behaves during a brownout.

Be sure to update the APIs to their latest version too. They need to be updated at the same time.

Yes. We updated the FW and then had to update the API due to the break in backwards compatibility. It went in the bag with 1.1.31. We are hoping to have our practice bot up and going late this weekend at which point we can resume testing. We can likely set something up on the bench before then and try to reproduce the problem but we haven’t gotten around to it yet.

@dyanoshak I’m assuming based on your response this isn’t a known problem? If we are able to reproduce it, is there anything else you would like us to try with the Spark Max in that state before cycling power?

Right, I haven’t seen this particular issue. Coincidentally, we were testing a different project with a SPARK MAX (running 1.1.31) yesterday that was consistently tripping the 40A breaker. Besides the breaker tripping, there were no other issues and the SPARK MAX would recover after the breaker turned back on.

Some video might help if you can consistently reproduce the issue. Another thing to help figure out what is going on would be printing the fault IDs to the terminal when the issue occurs:

for (CANSparkMax.FaultID c : CANSparkMax.FaultID.values())

EDIT: Tweaked the fault printing code.

Thanks! We’ll give that a try and report back with our findings.

We never ran into this again and it took longer than expected to get our practice bot up and going. It sounds like 1.1.33 fixes this?

Reading back to your original description, it sounds like the blink code may have actually been indicating a ‘DRV Fault’ which would match an issue fixed in v1.1.33

  • Fixes issue that causes a Gate Driver Fault if the NEO is spinning at a certain speed during power up.
    • e.g. while still moving after a breaker trips for more than ~1.4s after breaker recovery.