Board crashes when 12V is dropped after servo_init

[trickeydan]

This has caused me a lot of issues.

This seems to be due to the i2c being polled from a timer. When the 12V drops, the IO expander will stop responding, causing an error.

This could be resolved by:

a) Disabling the timer when 12V drops.
b) Adding a command to disable the timer.

[PeterJCLaw]

What is the useful scenario which could happen after 12V power has been lost? I appreciate that there could be a clearer handling of the error state for development (the only scenario where this issue has been reported), however from some perspectives crashing out feels like a reasonable response to the board becoming unusable.

[trickeydan]

What is the useful scenario which could happen after 12V power has been lost? I appreciate that there could be a clearer handling of the error state for development (the only scenario where this issue has been reported), however from some perspectives crashing out feels like a reasonable response to the board becoming unusable.

How about running code again without restarting the kit? It crashes the USB bus.

[PeterJCLaw]

Ah, crashing the whole USB bus isn't good. Even if we decide that the board entering a crashed state after power loss is ok, allowing that to affect other components clearly isn't.

In terms of re-running other code without restarting the kit, if we fix the crashing of the USB bus then this would become a non-issue as the new code would want to reset and re-initialise the peripheral boards anyway, which seems like it would void this issue?

Since the Servo Board draws its 12V power from the user-controllable outputs on the power board, I assume that also means that this state is one which competitors could get themselves into? It's interesting therefore that we haven't ever (to my knowledge) had anyone report issues from this.
This (competitors getting themselves into bad states) seems to me the most compelling reason to have a non-crashy handling of power loss.

What effect would disabling the timer have on the (normal) operation of the board?

[trickeydan]

this would become a non-issue as the new code would want to reset and re-initialise the peripheral boards anyway, which seems like it would void this issue?

Doesn't work. See https://pastebin.com/KQWjXRZe for the errors that occur.

Since the Servo Board draws its 12V power from the user-controllable outputs on the power board, I assume that also means that this state is one which competitors could get themselves into? It's interesting therefore that we haven't ever (to my knowledge) had anyone report issues from this.

I'm really surprised to be honest as this issue is so prevalent during our testing of this board before Smallpeice. I guess this may be due to them usually turning off their robot between code runs.

Kier has observed this issue with me also, and we think that it is essential that it is fixed before the summer school this year.

[PeterJCLaw]

I wonder whether the fact that the current SR stack gets pretty close to a reboot [1] even in the code-reload scenario anyway contributed to the lack of reports of this?

[1] As the overlay being used lives on the USB stick, removing the USB stick ends up killing the whole lot. When you reinsert the USB stick we end up pretty much fully booting again.

[trickeydan]

I now understand the SR stack futher.

As it pretty much does a whole reboot between every run, the usb lines are reinitialised, as in they power on and off. The side effect of this is that it gets around this issue.

For sbot, we have had to add an explicit workaround as our kit does not reboot every time.

The error otherwise occurs on every single run. Please ask me if you would like a demonstration of this.