We inadvertantly shorted our CAN bus today (“oh, that’s a shorting jumper, not a termination resistor?”), and the SparkMAX Java API threw an exception, immobilizing our robot.
Unhandled exception: edu.wpi.first.hal.util.UncleanStatusException: Code: -35007. Unknown error status
Error at com.revrobotics.CANSparkMaxLowLevel.getFirmwareVersion(CANSparkMaxLowLevel.java:283): Unhandled exception: edu.wpi.first.hal.util.UncleanStatusException: Code: -35007. Unknown error status
at edu.wpi.first.hal.CANAPIJNI.writeCANPacket(Native Method)
Robots should not quit, but yours did!
at edu.wpi.first.wpilibj.CAN.writePacket(CAN.java:77)
at com.revrobotics.CANSparkMaxLowLevel.getFirmwareVersion(CANSparkMaxLowLevel.java:283)
at com.revrobotics.CANSparkMaxLowLevel.<init>(CANSparkMaxLowLevel.java:239)
at com.revrobotics.CANSparkMax.<init>(CANSparkMax.java:146)
at org.usfirst.frc3620.robot.RobotMap.init(RobotMap.java:87)
at org.usfirst.frc3620.robot.Robot.robotInit(Robot.java:53)
at edu.wpi.first.wpilibj.TimedRobot.startCompetition(TimedRobot.java:63)
at edu.wpi.first.wpilibj.RobotBase.startRobot(RobotBase.java:263)
at org.usfirst.frc3620.robot.Main.main(Main.java:20)
The startCompetition() method (or methods called by it) should have handled the exception above.
I just notified REV support about this, but getting it “out there”. The idea of a intermittent CAN bus wiring fault rebooting the robot is not one I like.
I didn’t see any postings about this, but I’m not as adept with the new CD as I was with the old…
On a related note: how do I tell what version of the Spark MAX Java API I have? Does that auto-update once we add the vendor library to VScode, or do we need to manually update that?