search

joeycastillo / Sensor-Watch

A board replacement for the classic Casio F-91W wristwatch
Other
1.3k stars 250 forks source link

Backup dont overwrite on wake #474

Closed voloved closed 2 months ago

voloved commented 2 months ago

This issue was first noticed due to https://github.com/joeycastillo/Sensor-Watch/pull/387. This PR introduced reading and writing to the backup register in order to store birthdate and location. Its implementation is correct, but it did uncover a small bug.
On startup, we call app_setup, which writes the data in movement_state to the backup registers. This is good and at this point, those registers contain the defaults. However, app_setup also gets called when we wake from sleep. This means that the values in movement_state overwrite the backups. This is okay for the settings, as settings pass their pointer and get modified in every watch face, so movement_state.settings is always up-to-date.; birthdate and location don't have that luxury.

This PR moves the function that writes to the backup out of app_setup and into the line right above where app_setup gets called in main. There are 3 places where app_setup gets called on the watch: main, sleep, and deep_sleep, so only including this function in main seems appropriate.

The first commit in this PR also does this, but by reading the backup register before rewriting it on wake. This is a smaller change as no new functions are added, but a worse implementation. This is due to the watch reading the backup on wake, and then just writing what it just read back to the register.

This has been tested on hardware by:

  1. Going to sunrise face
  2. Verifying that the long and lat on it matches the DEFAULT in the code (which confirms we're writing to the backup on startup correctly)
  3. Changing the long and lat to something else.
  4. Waiting for LE time out.
  5. Waking from sleep
  6. confirming the default didn't overwrite it like the issue that started this investigation
joeycastillo commented 2 months ago

This goes too deep to try to address this problem. We shouldn't be hacking around in the core watch library loop to fix an issue in Movement. I will dig into this and try to fix the issue without going too deep. Do we have a sense for when this was introduced? I'd much rather revert whatever change caused this than try to work around it.