How to software reset a RoboClaw?

[jwatte]

I have RoboClaws in an embedded system that can self-program.
While it's self-programming, the motor power is off, but enough current leaks from the 5V rail into the RoboClaw that they power on, and detect logic battery under-voltage.
Once the system has self-programmed, it comes back, and turns main motor power back on.
However, the RoboClaws are still in error, blinking the red LED four times.

How do I reset the status of the roboclaws through the serial bus?

[Basicmicro Support]

You cannot. Errors can only be cleared by a hardware reset. This is to prevent a users program from simply clearing errors whenever they happen. Errors are telling you, you are about to damage your controller. All other status messages are warning which will clear once you have fixed the cause of the warning. An e-stop can be an error(latching) or a warning(non-latching).

1. You should not have an external 5v connected to the Roboclaws 5v. The two regulators will compete with each other causing excessive power disipation. You should only have a common ground if you are using seperate 5v power regulators(eg the Roboclaws and your embedded systems).

2. You may also be bleeding power from your I/O pins connected to the Roboclaw. Set these pins low before you start self-programming. This will prevent powering the roboclaw throught the I/O pins.

The low main battery status is a warning and will correct itself when you re-aply power. But the a Low logic battery status is an error so you need to make sure you either completely power it down when self-programming or your never let it go below 5.5v

[jwatte]

You should not have an external 5v connected to the Roboclaws 5v

I don't -- it's likely powering itself from the pull-up on the serial port on the MCU or perhaps there is some path to the motor power from the 5V regulator (presumably backwards through the other 5V regulator that's not powered.)

a Low logic battery status is an error so you need to make sure you either completely power it down

It's this that I'm not sure I can conveniently do. I can of course power cycle the whole system, but then that means power-cycling the Raspberry Pi that is programming the MCU, which takes a while to boot (because Linux doesn't boot fast these days )

I'll see if I can shut down the serial port and pull both TX/RX low after the MCU comes back (as part of start-up sequence,) and see if that makes the claw OK.

Some way of doing a full reset over the TTL bus would be nice, though!

[jwatte]

Yeah, the problem is that the power bus pulls up to 4V or so when only the MCU is powered. It can sit like this for a bit before it goes to full power on. This causes the 'claw to detect logic undervoltage, and thus it won't come out of error, even when the power bus comes back up to full voltage.

There's a design challenge here, though, because the regulator needs a protection diode from being back-powered:



This will power the RoboClaw with "too low" power whenever there is 5V back-power to the MCU and the main MOSFET switch is off. (Also I just saw that the MOSFET is turned the wrong way in this sketch -- sorry, it was a quick illustration

I think the best solution would be some way to reset the claw from software. If that's fundamentally against your religion (I hear what you say about people clearing errors when they shouldn't) then the second best would be to not treat a logic voltage error as error if the power voltage is also too low, at least not when first powering up.

[Basicmicro Support]

Based on the schematic the only path for power to the Roboclaw is RCLAW POWER and RCLAW RX/TX. The +5v going to RPI is not also going to the Robcolaw correct? That means the Roboclaw is being powered from the TX connection. If you cant programatically disable the TX pin when resetting the Roboclaw just add a 1k or 10k series resistor to the TX line. That will lower the maximum power through the TX pin to low enough that it cant power the Roboclaw through it.

If Im wrong please update the schematic with ALL wiring connections to all devices.

[jwatte]

The +5v going to RPI is not also going to the Robcolaw correct?

What's missing in the diagram is the label "USB" for the connection between RPi and MCU. USB does both data and power. The RPi has an on-board "ideal diode" to make forward/back feeding of the 5V rail okay.

Note the clamping diode going the "other way" across the voltage regulator.
The RPi powers the MCU when the voltage regulator isn't on. This feeds the diode. This feeds the claw power with a low voltage (5V minus Vf of the diode.) Yes, this means that there are two regulators involved; one that powers the RPi when programming the MCU, and one that powers the MCU and the RPi. There are "ideal diodes" involved so that ganging the regulators is OK.

For now, when I'm self-programming, I'm hooking vbat straight into the power bus, which avoids the power drop when the MCU drops the MOSFET gate getting programmed. It requires some re-routing to program, but it's better than re-spinning the full control board. I don't get the benefit of Vbat undervoltage cut-off, which normally goes through the MOSFET switch based on the MCU ADC, but I'll have to live with that and be careful to not leave it hooked up for too long.

I still want a UART-based full reset function

[Basicmicro Support]

Ah. I think I see the problem. The VBus 5v even though it isnt designed to power the Roboclaw is enough to keep it awake but at an undervoltage state. If that is the case you may be able to tell the R-Pi to disable the USB port to the Roboclaw(shutting off the 5v VBus).

[jwatte]

you may be able to tell the R-Pi to disable the USB port to the Roboclaw(shutting off the 5v VBus).

That has the side-effect of also turning off the Ethernet connection I'm using to connect to the Pi, the WiFi that's sending telemetry, and the microcontroller that I want to power. (And the touch screen that's hooked up, too, but that's less important.)

Still, that's an interesting idea, because I only need to do it specifically after having re-programmed the microcontroller, and getting ready to power up the full system for real. I'd still need to figure out a way to know when it's OK to turn the USB power back on again (as in, the microcontroller is back and has pulled main power to a safe level.) If that can be done, I would save having to power cycle the Pi, though, which is what I'm ultimately after.

Thanks for the idea!

Separately, please also consider my request to implement a software-based reset