[BUG] Print progress hangs at 3%

[classicrocker883]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

From this issue here: classicrocker883/MRiscoCProUI#229

it is confirmed that the Print Progress stays at 3% because of hal.watchdog_refresh();

void CardReader::selectFileByIndex(const int16_t nr) {
...
  hal.watchdog_refresh();
}

in src/sd/cardreader.cpp

Bug Timeline

🩹 Mitigate watchdog timeout for file ops See #28064, #28069

Expected behavior

Should not begin and stop at 3%

Actual behavior

Stays at 3%

Steps to Reproduce

1. So far confirmed on ProUI using Voxelab Aquila/Ender-3 V2/S1
2. Start Print

Version of Marlin Firmware

bugfix-2.1.x

Printer model

No response

Electronics

No response

LCD/Controller

No response

Other add-ons

No response

Bed Leveling

None

Your Slicer

None

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

No response

[ellensp]

Its hal.watchdog_refresh so its somewhat important you actually tell us what hal is being used!

You ignored the template and skipped all the importing information like the hardware it running on.

There are hints in your issue, but we shouldn't have to visit your issues and dig through all your code for the information that should be here.

For eg "TJC-Ender-S1-F4_SPRT13_UBL-ProUI-EX-10-01" this means almost nothing to us.

from "Ender 3 S1" im guessing it is a BOARD_CREALITY_V24S1_301F4
but from there we still have 4 build environment to guess at

env:STM32F401RC_creality
env:STM32F401RC_creality_nobootloader
env:STM32F401RC_creality_jlink
env:STM32F401RC_creality_stlink

Please fill in the form with as much information as possible

[classicrocker883]

it's many Hal, for STM32F401, STM32, STM32F1 (Maple), if it's for at least those it's gotta be for most if not all. it's not LCD related or otherwise.

There are hints in your issue, but we shouldn't have to visit your issues and dig through all your code for the information that should be here.

but you did anyway. and you can ask and get an answer later it's not like there's a rush

[1020alex]

hey rocker i think ill keep you updated. i think I refreshed the screen firmware and installed a newer one and I believed it fixed it. Give me a day or two? Or did you confirm this issue is non related to screen firmware?

[classicrocker883]

hey rocker i think ill keep you updated. i think I refreshed the screen firmware and installed a newer one and I believed it fixed it. Give me a day or two? Or did you confirm this issue is non related to screen firmware?

yea i confirmed it. with older firmware it began and showed 0% and when enabled it shot to 3% for the same file

[classicrocker883]

oddly enough, this might have been fixed with a recent commit to fix the SDSORT_QUICK stack, or it might have been a false positive all along.
Consequentially enough I have a file that begins with 3%. i have several test gcode files which begin with 3%, 0% and 2% when printing starts. I didn't realize it during testing, but I swear the only changes I did was commenting one line out and checking the same file.

but for now im going to close and write it off as a fluke since everything seems in order.