Do we need a 'soft reset' or a watchdog timer?

[blurfl]

What about adding a 'soft reset' command to GC?

Working with the firmware non-Arduino boards, I've run into an issue - Arduino Mega boards do a hard reset when the serial connection is established or when the DTR line is briefly strobed. GroundControl relies on the Arduino's behavior, expecting the firmware to be coming out of a reset state when it connects.
Many other boards (Teensy 3.5/3.6, GrandCentralM4) do not reset in this way. Instead they can be reset using software in response to a 'reset' command character. GRBL and MaslowDue use ctrl-x to trigger a reset. My issue could be addressed by having GC send the character as part of the connection process to reset the non-Arduino boards.
One convenient way to trigger the desired reset is with the boards built-in watchdog timer, so...

What about adding a watchdog timer to the firmware?

Presently the firmware runs whether or not there is a serial connection established. If for any reason the connection is broken (cable yanked, computer loses power, laptop sleep, etc.) the motors will continue to run until the last gcode line in the buffer is finished. That means the machine is running 'unsupervised', with no remote control. Is this a reason to have a watchdog to reset the firmware in certain circumstances, like loss of connection? The firmware would reset when the connection is lost, and loop at the beginning of its setup() until a connection is established.

Opinions? Alternate ideas?

[davidelang]

I don't think that a break is communication should result in a (potentially part destroying) halt. a firmware watchdog should be optional, but I don't think it's a bad idea to have one that's configurable. David Lang

[blurfl]

A break in communication does presently result in a halt. The act of (re)establishing the serial connection causes a hard reset to the Arduino Mega. This is unavoidable.

[blurfl]

establishing the serial connection causes a hard reset to the Arduino Mega. This is unavoidable.

I forgot about the jumper in the Mega reset circuit. If that is cut, establishing the serial connection won't cause a hard reset. The only way to reset or load a program will be to use the reset button on the Mega.

[BarbourSmith]

I think adding a soft reset command is a great idea. I think that there are cases where we could use that on the Mega also when we want to reload from scratch for example after wiping the eeprom.

Is there a way to do a soft reset that is consistent across multiple platforms?

[blurfl]

Is there a way to do a soft reset that is consistent across multiple platforms?

I propose to add a section to Gcode::readSerialCommands(), looking for a character like ctrl-x. If found, print a message to Serial like 'soft reset in 250ms.' Then start the watchdog with a 250ms timeout and loop waiting for the reset. I've got it up on the Mega and GrandCentral, Due and Teensy shouldn't be hard to do when needed.
The reset character would be a #define in ¿Config.h? The message is mostly for logging. The 250ms time span seemed reasonable, though a different value could be used. It's not real easy to make adjustable, though.
GC would send the character immediately after doing the serial open-close-open dance. There's cleaner way to do that, too.
Would you want to trigger the reset after the ERPROM clear from within the firmware, or from GC? Does the reset code need to be a separate function, or can it stay within Gcode::readSerialCommands()?

[BarbourSmith]

I think that sounds like a very well thought out plan. There is no reason for ctrl-x to turn up in a gcode file by accident, right?

I think putting it within readSerialCommands() sounds like the right thing to do for now. We can worry about if we want to call it when resetting the eeprom down the road