[BUG] POWER_LOSS_RECOVERY requires SD Card inserted at boot

[ne0nex]

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

Yes, and the problem still exists.

Bug Description

Enabled POWER_LOSS_RECOVERY, flagged as incompatible with SD_IGNORE_AT_STARTUP option. Disabled SD_IGNORE_AT_STARTUP option, and booted the unit without an SD card inserted.

The unit becomes unresponsive when booting without an SD card, having significant (or entirely frozen) menu UI, and sending gcode commands cause extremely slow or no response.

Connecting to the serial console in the failed state reveals continual spam of "No SD Card" in the terminal. The machine appears to be looping attempts to mount the SD card media (M21 perhaps)

Bug Timeline

This started once I enabled POWER_LOSS_RECOVERY

Expected behavior

It seems that the FW should more gracefully handle the lack of an SD card at boot when SD_IGNORE_AT_STARTUP is disabled. Looping and making the unit unresponsive does not seem like the intended behavior.

With SD_IGNORE_AT_STARTUP disabled, and no SD card in slot, Marlin should attempt to mount the SD card once, and then stop re-trying. Optionally, if POWER_LOSS_RECOVERY is enabled, this would be the time to warn the user via UI that power loss recovery is unavailable due to no SD card. (and to insert one)

Further, MarlinFW source should indicate this behavior in the documentation for POWER_LOSS_RECOVERY

Actual behavior

MarlinFW continually attempts to mount the SD card media causing an unresponsive unit.

Steps to Reproduce

Enable POWER_LOSS_RECOVERY
Disable SD_IGNORE_AT_STARTUP (advised to if one attempts to build with both of these on)
Build and flash unit
Remove SD card
Reboot unit (power off/power on)

Version of Marlin Firmware

2.0.9.4

Printer model

Creality Ender 3 - Pro

Electronics

SKR 1.3

Add-ons

BLTouch

Bed Leveling

ABL Bilinear mesh

Your Slicer

Cura

Host Software

Other (explain below)

Other things to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.
• Log output from the host. (M111 S247 for maximum logging.)
• Images or videos demonstrating the problem, if it helps to make it clear.
• A G-Code file that exposes the problem, if not affecting all G-code.

Additional information & file uploads

SerialOutput.txt
Configs.zip

[ne0nex]

so this is perhaps "Behaves Correctly" as I found the following:

in cardreader.cpp:

void CardReader::manage_media() {
  static uint8_t prev_stat = 2;     // At boot we don't know if media is present or not
  uint8_t stat = uint8_t(IS_SD_INSERTED()); // ne0nex: the problem is here, this is returning true when a card isn't in.
  if (stat == prev_stat) return;    // Already checked and still no change?

we're setting 'stat' = to true/false based on IS_SD_INSERTED() function call. later in the same function we have an if statement that checks if stat is true that does the attempt to mount and if not if SD_DETECT pin exists, release() the card :

if (stat) {
(do some stuff to try and mount)
  }
  else {
    #if PIN_EXISTS(SD_DETECT)
      release();                    // Card is released
    #endif
  }

we then indicate int he UI using ui.media_changed and then we check again for stat being false. if stat is false we return out of the function:

 ui.media_changed(old_stat, stat); // Update the UI or flag an error

  if (!stat) return;                // Exit if no media is present

so looking at IS_SD_INSERTED in cardreader.h:

#if ENABLED(USB_FLASH_DRIVE_SUPPORT)
  #define IS_SD_INSERTED() DiskIODriver_USBFlash::isInserted()
#elif PIN_EXISTS(SD_DETECT)
  #define IS_SD_INSERTED() (READ(SD_DETECT_PIN) == SD_DETECT_STATE)
#else
  // No card detect line? Assume the card is inserted.
  #define IS_SD_INSERTED() true
#endif

all but the bottom section is disabled (dimmed) for my config, critically the PIN_EXISTS(SD_DETECT) section. The only section remains is the hard-set to "true" so IS_SD_INSERTED() is always returning true causing the behavior.

It seems SKR1.3 board perhaps doesn't have SD_DETECT pin available, so IS_SD_INSERTED() will always return true, causing this behavior. So perhaps expected?

[CRCinAU]

Yep - you can't tell if a card is not inserted if there is no SD_DETECT... I believe this is pin 1 - or the CD DAT3 line.

As such, the only way to tell if a card is inserted is to try and read and then timeout...

[ne0nex]

Yep - you can't tell if a card is not inserted if there is no SD_DETECT... I believe this is pin 1 - or the CD DAT3 line.

As such, the only way to tell if a card is inserted is to try and read and then timeout...

That's what I'm thinking. However it doesn't seem that a timeout actually happens instead the machine is left in an unusable state.

[thisiskeithb]

Please download bugfix-2.1.x to test with the latest code and let us know if you're still having this issue.

[ne0nex]

merging bugfix-2.1.x into my personal repo to see if this reproduces. will comment here with results.

[dstrohl]

merging bugfix-2.1.x into my personal repo to see if this reproduces. will comment here with results.

Are you still running in to this? I am seeing the same thing with the released version of 2.1.

[thisiskeithb]

I am seeing the same thing with the released version of 2.1.

2.1 & 2.0.9.4 releases have various SD bugs, which is why I asked that OP download the latest bugfix-2.1.x since they should be resolved.

[ne0nex]

Apologies in the delay in checking this against bugfix-2.1.x. Unexpected medical issues, suck.

Regardless, I was able to merge bugfix-2.1.x into my personal repo for this machine and can confirm that the issue described above is now resolved. I have migrated my configs including POWER_LOSS_RECOVERY enabled, and tested various states of SD Card inserted and not inserted at boot up and at no point is the unit becoming unresponsive as before.

I like to keep my hardware at more stable releases (usually LTS) and usually move away from bugfix build trains. Is there a specific thing to watch out for, to see when these fixes get put onto 2.1 mainline?

[thisiskeithb]

Is there a specific thing to watch out for, to see when these fixes get put onto 2.1 mainline?

PRs sent to bugfix-2.1.x will later be merged into 2.1.x (And possibly backported to 2.0.x) at the maintainer’s discretion. You can watch the commit history or wait for the next 2.1.x release.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.