Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

lv_task_handler can fail to return in high load scenarios, causing watchdog resets

Offen
  • Stimmt etwas nicht?
#2,124 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Bug
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Bereich
embedded-iot, operating-systems

Rechercherichtung

Beginne damit, lv_task_handler und die im Issue beschriebene Interaktion zwischen DisplayApp und SystemTask nachzuverfolgen, und reproduziere dann den Lockup bei hoher Animationslast mit einer kürzeren LV_DISPLAY_REFR_PERIOD. Als erledigt gilt die Aufgabe, wenn der Task-Handler unter anhaltender Last zurückkehrt und die Nachrichtenwarteschlange nicht mehr zu Watchdog-Resets führt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug

The LVGL task handler re-evaluates higher priority tasks after executing lower priority ones
The animation task is higher priority than refresh tasks
If the animation task or refresh task takes a long time, after executing the refresh task the animation task may be ready again
This causes lv_task_handler to infinitely execute animation->refresh->animation->refresh etc without ever returning
If lv_task_handler doesn't return, the DisplayApp message queue becomes full (usually with touchscreen events) and blocks SystemTask, causing watchdog resets

This happens very rarely or even never in standard InfiniTime. But by either decreasing the LV_DISPLAY_REFR_PERIOD and increasing animation load (e.g animation scroll speed for labels in px/s) (I have not tested if both are required to trigger this behaviour, but I know that both are sufficient), it's possible to reproduce this lockup.

I'd suggest that we replace the LVGL task handler with one that provides a hard upper bound on the number of task executions. Perhaps by only executing each task once and exiting early if it's already spent too long doing work (many tasks waiting)? This would allow task priorities to still be usefully enforced. Lower priority refresh tasks might still get starved by animations though.

Possible cause for #2012 (the notification header scrolling animation)

Vorherrschende Sprache
C
Sterne
3.4k
Forks
1.1k
Ø Merge
13 Std. 32 Min.
Gemergte PRs (30 T.)
2

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus InfiniTimeOrg/InfiniTime

Alle Issues in InfiniTimeOrg/InfiniTime

Ähnliche Issues

Weitere Issues zu C

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.