Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1.11 - Chimes setting makes the font in the G7710 Watchface disappear #1411

Closed
1 task done
inhji opened this issue Nov 1, 2022 · 14 comments · Fixed by #2019
Closed
1 task done

1.11 - Chimes setting makes the font in the G7710 Watchface disappear #1411

inhji opened this issue Nov 1, 2022 · 14 comments · Fixed by #2019
Labels
bug Something isn't working

Comments

@inhji
Copy link

inhji commented Nov 1, 2022

Verification

  • I searched for similar bug reports and found none was relevant.

What happened?

After the watch woke up due to the chimes setting, the font disappeared

What should happen instead?

Waking up from chimes should show the normal complete watch face

Reproduction steps

This is what triggers the bug for me:

  • Set the chimes setting to 30 min (have not tested 1 hours yet)
  • Let the watch turn off by it self and wait for the next 30 min mark
  • The watch turns on at the mark and the font is gone

The watchface can be restored by going into the settings and then returning back to the watchface.

More details?

No response

Version

1.11

Companion app

Flashed with itd

@inhji inhji added the bug Something isn't working label Nov 1, 2022
@minacode
Copy link
Contributor

minacode commented Nov 1, 2022

I searched for similar bug reports and found none was relevant.

This is #1376, right? 😉

Edit: ok, maybe not exactly..

@inhji
Copy link
Author

inhji commented Nov 1, 2022

This is what it looks like (sorry for the blurry picture). If this behaviours stems from the same source, I'll happily close this issue :)

PXL_20221101_203009809

@minacode
Copy link
Contributor

minacode commented Nov 1, 2022

This looks different, so it's fine. I think you are right and it stems from the same underlying issue, but keep it open, because it is relevant and no duplication.

@HugoMskn
Copy link

HugoMskn commented Nov 1, 2022

I have the exact same problem, but you found the cause
IMG_20221102_000023

@ITCactus
Copy link

ITCactus commented Nov 2, 2022

indeed, it's a different issue.
looks like in this case external resources (fonts/images) are not displayed (tried with Infineat face #1024, Casio G7710 #1122, and Digistyle #1116).

note: while the issue claims it's for "G7710", the issue itself looks like system-wide. anyway, i will not be able to fix or debug the issue. so, anyone skilled for this case, feel free to bash this bug.

@mark9064
Copy link
Member

mark9064 commented Mar 4, 2023

I can also reproduce this. When it wakes for the chime, the numbers are visible for an instant (can't tell if they are correct) before being replaced with the blank boxes as above. I tried the simulator (InfiniSim) and could not reproduce the issue there. This is on the 1.11 release

@nand11
Copy link

nand11 commented Apr 12, 2023

I can reproduce this issue on 1.12. Scrolling up and down makes the font come back. But next time the watch wakes up, the font is gone again.

@JF002
Copy link
Collaborator

JF002 commented Apr 16, 2023

I've never been able to reproduce such issue. My best guess is that sometimes LVGL cannot allocate a chunk of memory big enough to hold the whole font. This will hopefully be fixed with #1709 since more memory will be available to the watchface (I ran this branch for several days with chimes enabled and never noticed such issue).

However, there seems to be 2 behaviors : the font is just not displayed or it's corrupted. And I'm not sure if both behaviors are caused by this issue.

@FintasticMan
Copy link
Member

I've been able to reproduce the issue of the font not being displayed at all with a build that has the unified heap. The min free value in SystemInfo reads 3024 after it happened, which leads me to believe that the issue isn't that there isn't enough free memory to allocate the font. I can't remember what the min free was before the chimes activated, so I'm not sure if it was higher before.

@minacode
Copy link
Contributor

minacode commented Apr 18, 2023

It could be a data race. Here is my theory without testing.
Tldr: We need better syncronization of our concurrenct tasks when they use hardware components.

In SystemTask.cpp there is

case Messages::OnNewHour:
  // ...
  GoToRunning();
  displayApp.PushMessage(Pinetime::Applications::Display::Messages::Chime);

The SystemTask and the DisplayApp run concurrently, so there could be a data race.

GoToRunning sets the SystemTask to WakingUp and queues the message GoToRunning:

void SystemTask::GoToRunning() {
  if (state == SystemTaskState::Sleeping) {
    state = SystemTaskState::WakingUp;
    PushMessage(Messages::GoToRunning);
  }
}

Once that message gets handled

case Messages::GoToRunning:
  // ...
  spiNorFlash.Wakeup();
  // ...
  displayApp.PushMessage(Pinetime::Applications::Display::Messages::GoToRunning);

is called.

Meanwhile in the DisplayApp there is:

case Messages::Chime:
  LoadNewScreen(Apps::Clock, DisplayApp::FullRefreshDirections::None);

which creates a watch face that (in the case of the casio watch face) calls

if (filesystem.FileOpen(&f, "/fonts/lv_font_dots_40.bin", LFS_O_RDONLY) >= 0) {
  filesystem.FileClose(&f);
  font_dot40 = lv_font_load("F:/fonts/lv_font_dots_40.bin");
}

and the filesystem is implemented as

int FS::FileOpen(lfs_file_t* file_p, const char* fileName, const int flags) {
  return lfs_file_open(&lfs, file_p, fileName, flags);
}

I am not sure about the internals of littlefs, but does this check if the memory is actually available?

What if the DisplayApp handles the Chimes message and creates the watch face before the SystemTask handles the GoToRunning message?
It seems like in that case the FileSystem would read from memory that was not woken up yet.
And if that read does not crash (which I don't know 😁) then whatever gets loaded is null or gibberish.

@mark9064
Copy link
Member

Seems like you are right on the money minacode. I tried a small patch as so
Messages::GoToRunning

           state = SystemTaskState::Running;
+          if (sendChimeAfterWake) {
+            displayApp.PushMessage(Pinetime::Applications::Display::Messages::Chime);
+            sendChimeAfterWake = false;
+          }
           break;

Messages::OnNewHour/OnNewHalfHour

           if (state == SystemTaskState::Sleeping) {
+            sendChimeAfterWake = true;
             GoToRunning();
-            displayApp.PushMessage(Pinetime::Applications::Display::Messages::Chime);
            }

and the issue has been resolved. This change probably isn't sound (I haven't verified), but I think your identification of the root cause is correct

@minacode
Copy link
Contributor

Nice work! 😊
I think we need a more general approach that ensures that hardware is available when being accessed.

@nickalcock
Copy link

Aside: I see this with Infineat as well as of 1.13.

@JF002
Copy link
Collaborator

JF002 commented Mar 12, 2024

@minacode, @mark9064 thanks for this analysis of the issue and for the fix in #2019!

Tldr: We need better syncronization of our concurrenct tasks when they use hardware components.

Yes, I totally agree with you! This part of the code evolved organically, and probably deserve a nice refactoring :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants