Closed febbyeka closed 2 years ago
I just rebuild my firmware with following options :
Enabled:
Disabled:
After reflash my printer, power-up and boot normally performed, even when SD card is inserted.
I don't know which option, but I assume disabling show_custom_bootscreen solved this
Unfortunately, I have the SHOW_CUSTOM_BOOTSCREEN
option disabled, but my printer still does not start with the SD card in the slot.
Do you have the same electronics ? Maybe you could try to disable another lines as I mentioned
Maybe try formatting your sdcard, it may be corrupted
I haven’t tried to format my card though
The same thing is happening on my 4.2.7 Board. I tried formatting the card, but I know that's not the issue because before that I flashed back to Creality's version and it boots up fine with the card inserted.
Tonight I rebuild my firmware again. Adding filament runout capability. My printer still boot and operate normally with SD card inserted
Today I tried to use vanilla config with some minimal changes related to my machine. Built the firmware but the result is still the same. The printer does not start with SD inserted. I also tried to disable SDSUPPORT
and the printer starts without any issues.
Finally, I found the solution. I replaced the SD card with a new one and now everything works fine. The firmware starts without any issues with a new SD card inside. I don't know why it did not work with the previous card. I tried to format it into FAT and extFAT but without any luck.
I've seen this behavior on my 4.2.2 and 4.2.7 boards as well. I believe I first saw this in bugfix sometime around early August.
Finally, I found the solution. I replaced the SD card with a new one and now everything works fine. The firmware starts without any issues with a new SD card inside.
Same here, I have one particular SD card that causes the behavior while others work fine. My Windows PC can still read/write the card and I can use the card to flash the firmware, but it would appear there is something with it that's causing this. In my case, the sdcard is the cheap one included with the printer, so I just chalked it up to it going bad...
Finally, I found the solution. I replaced the SD card with a new one and now everything works fine. The firmware starts without any issues with a new SD card inside. I don't know why it did not work with the previous card. I tried to format it into FAT and extFAT but without any luck.
Is it the same size/brand/class ? Could you confirm about the format of your new card (NTFS/FAT32/etc) ?
Is it the same size/brand/class ? Could you confirm about the format of your new card (NTFS/FAT32/etc) ?
No, it's completely different. It has 16GB instead of 4 and class 10 instead of 4. I'm not 100% sure about the format, but it should be FAT32.
I have the same problem with different MKS Robin Nano boards on STM32F1 and STM32F4. The problem is not permanent, so it is not very easy to debug it. The problem appeared after replacing the libmaple library with a HAL from ST. The card initialization process (SD_init() function) does not always complete successfully. The file system does not matter, the problem is at the initialization stage of the card itself. The initialization process freezes, and if watch dog is enabled, the board restarts. ststm32 library version currently in use - 12.1 Perhaps in newer versions (actual is 14.2.0) the problem has already been fixed.
One and the same card works stably in 2.0.7.2 (with libmaple) and sometimes crashes in 2.0.9.2
Has this been solved? Same issue happen on 2.0.9.3 with an FLSUNHiSpeed board (stm variant). It then leaves the system in this state until I reload the firmware and have to retune / restore / reconfigure all parameters ( pid, delta calibration, etc.)
I have the same problem, using SKR2 revb, 2.0.9.3 and latest TFT70 fw compiled with no errors. Even an empty sdcard 32 GB, fat 32 / 4096, inserted to TFT70 sd prevents it to boot. If I boot without sdcard and after that I insert the card, the sdcard works and printing from it goes ok.
I've been experiencing a related problem with my system. I have an Ender 3 Pro with 1.1.4 board and I've upgraded to use the CR Touch bed leveling system. The BL Touch firmware from Creality is crap and doesn't seem to appropriately use the Z-Offset value once it has been set. After I installed the Ender 3 configuration of Marlin the machine mostly works great with one troubling issue. When I go to perform a bed level the system sometimes resets in the middle of the operation. It doesn't seem to matter whether I heat + level or a level bed without heat and it resets at different times during the bed-leveling. The LCD display will blank out and reboot, sometimes asking if I would like to recover my print and sometimes directly back to the main screen. If I burn the original Creality BL Touch firmware, I don't have this issue. I've considered that maybe it's not firmware related but only appears when I use the Marlin 1.1.9+Fix. I didn't think it was related to the SD card but with further exploration, I have found that while using the LCD menu to access gcode files to print, the interface is sluggish and it's difficult to select a file. This behavior seems to occur when I have the original 8GB SD card inserted that came with the printer several years ago. I have tried reformatting the original SD card but it doesn't make a difference. If I do not insert an SD card, I sometimes experience the random bed leveling restart or at the end of the bed-leveling the LCD screen locks-up and I must toggle the power switch to restart the system. When I swap out the SD card for another of the same size, the LCD menu behaves normally and so does the bed-leveling. My theory so far is either there is a firmware issue or there is an issue with the system memory and the SD card and bed-leveling reveal the issue. I can think of two more tests I can perform to further isolate this issue. I have an identical Ender 3 Pro machine setup, same board version, and upgrades except it uses the magnetic bed instead of glass. I will try testing that machine with the SD card. The only other test I can think to try is to swap out the board for another.
I have confirmed that my second Ender 3 Pro with identical hardware ( except for the magnetic bed instead of glass ) has the exact same issue. If I do not insert an SD card, I sometimes experience the random bed leveling restart. I've determined that I have the same issues on both machines and I am sometimes able to perform a bed-level and use the machine as expected. Unfortunately, it doesn't seem to matter whether an SD card is present or not so that seems to be incidental.
This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.
I am getting the same issue with an SKR mini V3. I compiled firmware today for my SV03. I was getting an infinite boot loop. However, when I took the SD card out, it booted up. As soon as I insert the card, Marlin restarts.
I'm having the same issue with my SKR E3 Mini V3, on my Ender 5.
@tiagofreire-pt: Don't paste your configs here. Zip them up and attach them as a single file instead so we don't have to scroll forever in this issue.
Similar to the: https://github.com/MarlinFirmware/Marlin/issues/21524
@tiagofreire-pt: Don't paste your configs here. Zip them up and attach them as a single file instead so we don't have to scroll forever in this issue.
Thanks for the warning. I made a change, using the github 'details' markdown.
Thanks for the warning. I made a change, using the github 'details' markdown.
@tiagofreire-pt: No, you need to zip them up as a single zip file and attach them.
The issue seems to be not related with the configuration, but rather the HAL source code: https://github.com/MarlinFirmware/Marlin/commit/6e0b79a33b7e6d5405be6d0ae5b16e5f3fd62fac
Possible fix: https://github.com/MarlinFirmware/Marlin/issues/21524#issuecomment-972804394
I'm having the same issue with MKS Robin Nano V.1.2
Hello.
I tried to find the reason why the card is not working. I tested on MKS Robin 1.1, with stm32f103ve and sd card connected by SDIO.
On both branches, bugfix-2.1.x and 2.1.x the card does not mount with the message "Media Init fail" in 10 cases out of 10. I have tried several cards, none work.
It turned out that the problem was switching the card to work in 4-bit mode.
SDIO_Init() in Marlin/src/HAL/STM32/sdio.cpp:
sd_state = HAL_SD_ConfigWideBusOperation(&hsd, SDIO_BUS_WIDE_4B);
This function return HAL_ERROR and mounting fail. The HAL_SD_ConfigWideBusOperation function is inside the HAL, not in the marlin code. Inside this function, the SCR register of SD card is read, the operation bit is checked in 4-bit mode, the card is commanded to switch to 4-bit mode and the SDIO is configured to 4-bit mode. The problem is that the SCR register is sometimes read as 0. The register read correctly when running under the debugger, but always returned 0 during normal operation. The check for the possibility of working in 4-bit mode fails and the function returns an error. All modern SD cards support 4-bit operation. I don't think it will be possible to find a card that does not support this mode.
I didn't figure out how to fix it in the HAL. To solve the problem, I simply moved the switch to 4-bit mode directly into the marlin code (inside SDIO_Init). In my case, this completely solved the problem. The card is connected and working. It would be nice if someone tested this solution. I haven't done a PR yet as I haven't found the exact problem and this is more of a workaround.
Here is the whole SDIO_Init() function (Marlin/src/HAL/STM32/sdio.cpp line 201):
bool SDIO_Init() {
HAL_StatusTypeDef sd_state = HAL_OK;
if (hsd.Instance == SDIO){
HAL_SD_DeInit(&hsd);
}
/* HAL SD initialization */
hsd.Instance = SDIO;
hsd.Init.ClockEdge = SDIO_CLOCK_EDGE_RISING;
hsd.Init.ClockPowerSave = SDIO_CLOCK_POWER_SAVE_DISABLE;
hsd.Init.BusWide = SDIO_BUS_WIDE_1B;
hsd.Init.HardwareFlowControl = SDIO_HARDWARE_FLOW_CONTROL_DISABLE;
hsd.Init.ClockDiv = clock_to_divider(SDIO_CLOCK);
sd_state = HAL_SD_Init(&hsd);
#if PINS_EXIST(SDIO_D1, SDIO_D2, SDIO_D3)
if (sd_state == HAL_OK) {
//Fix 4b sdio
//sd_state = HAL_SD_ConfigWideBusOperation(&hsd, SDIO_BUS_WIDE_4B);
SDIO_InitTypeDef Init;
uint32_t errorstate;
/* Send CMD55 APP_CMD with argument as card's RCA.*/
errorstate = SDMMC_CmdAppCommand(hsd.Instance, (uint32_t)(hsd.SdCard.RelCardAdd << 16U));
if(errorstate != HAL_SD_ERROR_NONE)
{
return false;
}
/* Send ACMD6 APP_CMD with argument as 2 for wide bus mode */
errorstate = SDMMC_CmdBusWidth(hsd.Instance, 2U);
if(errorstate != HAL_SD_ERROR_NONE)
{
return false;
}
/* Configure the SDIO peripheral */
Init.ClockEdge = hsd.Init.ClockEdge;
Init.ClockBypass = hsd.Init.ClockBypass;
Init.ClockPowerSave = hsd.Init.ClockPowerSave;
Init.BusWide = SDIO_BUS_WIDE_4B;
Init.HardwareFlowControl = hsd.Init.HardwareFlowControl;
Init.ClockDiv = hsd.Init.ClockDiv;
(void)SDIO_Init(hsd.Instance, Init);
/* Change State */
hsd.State = HAL_SD_STATE_READY;
//Fix 4b sdio
}
#endif
return (sd_state == HAL_OK) ? true : false;
}
Changed part is inside "//Fix 4b sdio".
Changed part is inside "//Fix 4b sdio".
Thanks for the input, I applied your patch and it works like a charm. The test was done with the latest BugFix (bump 22-07-04) with an STM32F1(HAL32) and TFT28/32/35 (FSMC) screens and several SD card types (4/16GB class 4 and class10).
If I remember right, the old sdio code tries 4b and if it fail, it fallback to 1b.
This is the original sdio code: https://github.com/MarlinFirmware/Marlin/blob/52eefa90e1c18616f127cdf43798907880e05ee5/Marlin/src/HAL/STM32/sdio.cpp
if you look here: https://github.com/MarlinFirmware/Marlin/blob/52eefa90e1c18616f127cdf43798907880e05ee5/Marlin/src/HAL/STM32/sdio.cpp#L221
You will see that it tries enable 4b, then fallback.
If this fallback code do exists, THERE’S a reason for this.
I really don’t know why the sdio code was totally changed with apparently no testing!!
i think we should rollback the sdio changes, going back the what was stable, then take a look and the pr that changed it and just add the new parts.
Please test/report findings in https://github.com/MarlinFirmware/Marlin/pull/24470
I really don’t know why the sdio code was totally changed with apparently no testing!!
i think we should rollback the sdio changes, going back the what was stable, then take a look and the pr that changed it and just add the new parts.
I completely agree. That's the reason I called my patch "smart". I only restored the read/write functions but I see unreliability on SD initialization and when a card is removed and then reinserted.
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.
Did you test the latest
bugfix-2.0.x
code?No, but I will test it now!
Bug Description
I'm new to Marlin, and relatively new to 3d printing. This is my first printer, Ender-3 with 4.2.2 Mainboard. Default FW was Marlin 2.0.1 I build Marlin 2.0.9.2 with vscode, platformio, and auto-build. I choose STM32F103RET6_creality envronment Build was succesfull and I can update my Ender-3, pass the first boot and initialize eeprom. After that, printer gives bootloop between Ender-3 and Marlin screen if turned on with SD Card is inserted. I tried 2 SD cards. But if SD card is not inserted it can boot normally.
Bug Timeline
Ever since I updated it to 2.0.9.2
Expected behavior
I expect it to boot normally with SD Card inserted
Actual behavior
Bootloop between Ender-3 and Marlin screen if turned on with SD Card is inserted
Steps to Reproduce
Version of Marlin Firmware
2.0.9.2
Printer model
Creality Ender 3
Electronics
stock with board 4.2.2
Add-ons
no add-ons
Bed Leveling
No Bed Leveling
Your Slicer
Cura
Host Software
No response
Additional information & file uploads
No response