activity: re-sync charging gate so step tracking can't wedge off

[Coral-coder]

Problem

Step tracking is gated by enabled_charging_state (tracking is disabled while plugged in). That flag is only ever updated from battery state-change events. If a charger-disconnect event is ever missed — we hit this in the field when battery updates were delayed — the gate stays stuck "as if plugged in" and step counting silently stays off until reboot. There is no recovery path: the tracking-gated cron is torn down while tracking is stopped, so nothing ever re-evaluates the gate.

Fix

Add an always-on once-a-minute regular_timer callback (registered in activity_init, independent of the tracking-gated machinery) that:

1. re-derives the charging gate from the live battery_is_usb_connected() state, and
2. re-kicks a start that should have happened but didn't (should_be_started && !started while allowed).

Re-evaluation goes through the existing prv_handle_activity_enabled_change() path on the system task, and prv_set_enable_cb is idempotent, so a redundant re-kick is a no-op. In the steady state the callback compares one bool and returns. Bigboards keep their existing behavior (CONFIG_IS_BIGBOARD excluded, same as the charger event handler).

Testing

• Unit test added: forcing the wedged state (gate stuck while unplugged) and firing the minute callback restores tracking; full waf test suite passes.
• Field-tested on SF32LB52 (Obelix): reproduced the wedge via missed charger events, confirmed step counting self-heals within a minute instead of requiring a reboot.

Second commit initializes regular_timer in the activity test harness so the new registration is exercised.

[ericmigi]

nice catch!

[gmarull]

Problem

Step tracking is gated by enabled_charging_state (tracking is disabled while plugged in). That flag is only ever updated from battery state-change events. If a charger-disconnect event is ever missed — we hit this in the field when battery updates were delayed — the gate stays stuck "as if plugged in" and step counting silently stays off until reboot. There is no recovery path: the tracking-gated cron is torn down while tracking is stopped, so nothing ever re-evaluates the gate.

Fix

Add an always-on once-a-minute regular_timer callback (registered in activity_init, independent of the tracking-gated machinery) that:

1. re-derives the charging gate from the live battery_is_usb_connected() state, and
2. re-kicks a start that should have happened but didn't (should_be_started && !started while allowed).

Re-evaluation goes through the existing prv_handle_activity_enabled_change() path on the system task, and prv_set_enable_cb is idempotent, so a redundant re-kick is a no-op. In the steady state the callback compares one bool and returns. Bigboards keep their existing behavior (CONFIG_IS_BIGBOARD excluded, same as the charger event handler).

Testing

• Unit test added: forcing the wedged state (gate stuck while unplugged) and firing the minute callback restores tracking; full waf test suite passes.
• Field-tested on SF32LB52 (Obelix): reproduced the wedge via missed charger events, confirmed step counting self-heals within a minute instead of requiring a reboot.

Second commit initializes regular_timer in the activity test harness so the new registration is exercised.

It seems like this is papering over a bug (missed events). Can you confirm this is true? What is the root cause of this problem?

[Coral-coder]

In my case, I had a bad charge cable and it kept disconnecting and connecting rapidly, it wedged off the step counter when I disconnected.

might be an edge case, but it fixed the issue.

[gmarull]

In my case, I had a bad charge cable and it kept disconnecting and connecting rapidly, it wedged off the step counter when I disconnected.

might be an edge case, but it fixed the issue.

Before merging this I'd like to get more details, seems like the real problem is the event missed for some unknown reason. Adding logs and using your bad cable should shed some light.

[Coral-coder]

alright, will take me a bit to find that cable again... I think I threw it out...

[Coral-coder]

Unable to find cable. close it if it doesn't seem like a fix for an edge case I guess..