Battery charging has race if EXT power bounces quickly

[rsmith]

If the external power bounces quickly then the EC will turn off the IO controlling the charging mosfet but other parts of the code will fail to detect the change. Thus the result is that the battery is not getting charged but the charging LED is enabled and the battery code thinks its charging.

The core of the problem is that there are several different parts of the code that frob the charging state and they get out of sync. Each has its own logic. Fixing this properly where only 1 system makes the charge/no charge decision will involve a fair bit of refactoring in various parts of the code. Enough that I don't want to do it so close to mass production.

EC code 1.9.21 contains a workaround of extending the debounce time for EXT power loss from 120ms to 500ms. In my tests this seems to give enough time for all parties to decide we lost EXT power. Ver 1.9.21 also has the charge LED tied to the state of the IO pin for the mosfet so if the race does still occur at lest the EC wont lie to you.

[rsmith]

After further testing I've identified that the race can still be triggered.

If you time the EXT power resume to coincide with the end of the AC loss debounce period then you trigger the race.

You can duplicate this by unplugging the power a few times while watching the LED to get the timing and then anticipate when the LED will go out. Re-insert power at that instant and you trigger the race.

I've also verified that the EC charge LED correctly matches the state when this happens now that its bound to the IO. So it won't charge but the LED is not incorrectly lit.

[rsmith]

Fixed when MPPT refactor happened. Already in build.