[Upstream #3908] Idle priority threads that only yield can lock up serial USB if qFlipper is in use

[joseguzman1337]

Originally from: flipperdevices#3908
Original author: @CookiePLMonster
Created: 2024-09-18T08:39:26Z
State: closed

---

Describe the bug.

This bug report only mentions the Direct Draw debug app, since it's the easiest to reproduce this issue on that app - however, appears to happen in any other app that is running at an idle priority and only uses yielding to relinquish CPU time.

Attempting to run qFlipper when a Direct Draw debug app runs, then terminating it, and attempting to either:

• run qFlipper again
• deploy an app
• connect to CLI

returns in these actions locking up and failing. ufbt cli gets stuck at

scons: Entering directory `H:\dev\flipper-zero\.ufbt\current\scripts\ufbt'
python H:\dev\flipper-zero\.ufbt\current\scripts/serial_cli.py -p auto
--- Miniterm on COM6  230400,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---

and never shows the Flipper logo prompt, deployments halt, qFlipper cannot detect the Flipper.

Terminating the app "unstucks" the connections. Also this does not happen with all serial connections, CLI can be started as many times as I wish - the state only locks up after running qFlipper.

As far as I can tell, this is not related to direct drawing, rather to the thread priorities again - as replacing furi_thread_yield() with furi_delay_tick(2) resolves this issue. However, since the app thread is running at an Idle priority, it should make space for any other task that needs CPU time, I think?

Reproduction

1. Connect the Flipper to the PC.
2. Run a Direct Draw debug app.
3. Run ufbt cli - notice the command goes through and it shows a Flipper prompt.
4. Terminate the CLI connection.
5. Run qFlipper, and exit it as soon as it shows the mirrored screen.
6. Attempt to run ufbt cli again - notice it gets stuck at --- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---.
7. Terminate the Direct Draw debug app. Notice the CLI session gets unstuck.

Target

f7 running on stable 1.0.1 firmware

Logs

No response

Anything else?

No response