CLI: Fix long delay with quick connect/disconnect

[WillyJL]

What's new

• fixes the 5-10 second delay when cli is started and stopped before cli shell can start properly
• noticeable with qflipper, for some reason it sets DTR on/off/on again so flipper starts CLI, stops it, then starts again; but cli shell is trying to print motd, and pipe is already broken so each character of motd times out for 100ms
• changing pipe timeout from 100ms to 10ms for cli shell works too, but is just a workaround
• it didnt always happen, i think that variable time of loading ext cmds made it so on ofw it usually manages to print motd before pipe is broken; on cfw with more ext commands it always hung, on ofw only sometimes
• unrelated to the bug, also made cli vcp cleanup the cli shell on disconnect instead of next connect so it doesnt stay around after disconnecting usb, might free a little ram maybe

before:

Kooha-2025-07-22-18-03-41.mp4

after:

Kooha-2025-07-22-18-05-32.mp4

Verification

• qflipper opens and connects quickly as expected

Checklist (For Reviewer)

• PR has description of feature/bug or link to Confluence/Jira task
• Description contains actions to verify feature/bugfix
• I've built this code, uploaded it to the device and verified feature/bugfix

[portasynthinca3]

@WillyJL could you please test the latest commit on your FW with your set of plugins? I believe a constant delay is more robust than a variable delay introduced by cli_shell_init.

[WillyJL]

@WillyJL could you please test the latest commit on your FW with your set of plugins? I believe a constant delay is more robust than a variable delay introduced by cli_shell_init.

that does work too, either way is fine for me. i dont really love that this is just artificially making it slower, if it is actually connecting for real it still has to load plugins after so its slower overall, but its not a huge deal for just 100ms. by checking after cli_shell_init() it could continue on with no time loss if its actually connecting, or stop if it was a fake connect. though also true that maybe plugins take longer than 100ms so in the fake connect it could take longer than 100ms to realize.

[WillyJL]

actually, qflipper seems to sleep 50ms, but 100ms sounds safe in case theres latency of some kind. but this could make it faster for the fake connect to leave earlier (it feels faster to me opening qflipper):

diff --git a/lib/toolbox/cli/shell/cli_shell.c b/lib/toolbox/cli/shell/cli_shell.c
index 8bf5839002..fa5cdc628a 100644
--- a/lib/toolbox/cli/shell/cli_shell.c
+++ b/lib/toolbox/cli/shell/cli_shell.c
@@ -461,13 +461,13 @@ static void cli_shell_deinit(CliShell* shell) {
 static int32_t cli_shell_thread(void* context) {
     CliShell* shell = context;
 
-    // Give qFlipper a chance to close and re-open the session
-    furi_delay_ms(100);
-
-    // Sometimes, the other side closes the pipe even before our thread is started. Although the
-    // rest of the code will eventually find this out if this check is removed, there's no point in
-    // wasting time.
-    if(pipe_state(shell->pipe) == PipeStateBroken) return 0;
+    // Sometimes, the other side (eg qFlipper) closes the pipe even before our thread is started. Although
+    // the rest of the code will eventually find this out if this check is removed, there's no point in
+    // wasting time. This gives qFlipper a chance to quickly close and re-open the session.
+    for(uint8_t i = 0; i < 10; i++) {
+        furi_delay_ms(10);
+        if(pipe_state(shell->pipe) == PipeStateBroken) return 0;
+    }
 
     cli_shell_init(shell);
     FURI_LOG_D(TAG, "Started");

if thats fine with you

EDIT: to be honest, i tried editing that code out of qflipper and it still works fine, i wonder if DTR is just set high normally when opening the port and qflipper is doing this for nothing (i didnt use minicom or other tools besides qflipper while testing, and it always did that DTR reset)

[portasynthinca3]

@WillyJL Yep, looks good!