Latest firmware bootloops when compiled from scratch for Ender 3 S1 F4 #1180
Comments
|
Thanks, that issue was reported first here: #1164 (reply in thread) Indeed the current sources and precompiled firmware for the F4 202312XX version have a bug that prevents to reboot. Unfortunately I don't have that board for do the proper debug. I suspect about the CRC corruption in settings.cpp. I need the debugging information sent by the printer to a serial console when the printer reboots. |
|
Ok I will try to get that info tonight. I tried several configurations and even manually disabled the items you mentioned in your post to reduce program size but still gets the same result. Last time I hooked the serial console up during boot it read back mostly garbage characters but eventually I started to see repeating "SD bootloader" and then the name of the bin file over and over. That was using baud 115200, all other baudrates were illegible. |
|
Thanks, try with the baud rate in 250000 |
|
I have experienced this same or a similar issue with my F4 S1, when trying to load a custom-compiled professional firmware from SD card the printer is stuck on the "wait for reboot" screen and stays like this until another firmware is flashed. When connected to a host (pronterface at 250000 baud), this is the output I received:
This repeated until the printer was turned off, and rebooting even without the SD card inserted produced the same output. By disabling EEPROM_AUTO_INIT and EEPROM_INIT_NOW and adding DEBUG_EEPROM_READWRITE in Configuration.h and recompiling I was able to get the custom firmware to boot, though it would give the message "Error: EEPROM CRC" on the printer screen at startup and when rebooted would discard any saved settings. Sometimes a message with "EEPROM Size" would show on the printer screen as well. |
|
Thanks, that confirms my suspicions, CRC was corrupt. So, a firmware where CRC is tested at different places is needed to discover where it is being corrupted, please enable DEBUG_EEPROM_READWRITE and paste here the serial console results. |
|
Just got home and tried it as well looks like i got the same thing. Marlin ProUI Version: 2.1.3 MRiscoC |
|
Here is the output I received when DEBUG_EEPROM_READWRITE was enabled and EEPROM_BOOT_SILENT was disabled:
When EEPROM_AUTO_INIT and EEPROM_INIT_NOW were disabled, this is what I got on boot:
I then clicked the "Store Settings" option on the printer, which slowly output these:
At this point the printer froze and quickly rebooted. When the reboot finished, Err: EEPROM Version showed on the printer's status bar. On subsequent reboots this does not happen when saving settings, though settings are still not saved when turning the printer off and on. |
that is also something I have experience. but only using Bilinear_auto_bed_leveling where it wouldn't save the mesh |
|
It looks like the problems are with these settings: Quick fix: comment out everything about these settings in Marlin\src\module\settings.cpp |
Thanks for your findings, but I can't understand why F4 UBL version doesn't suffer of bootloops. Trying to give more details, if follow your steps. there isn't a bootloop, but ¿are the settings saved and loaded correctly? |
|
I made the changes suggested by @Arturchik29, commenting out all instances of motor_current_setting and tmc_sgt in settings.cpp, as well as changing the EEPROM version to P90. At least in my case, the printer was able to save and load settings on reboot when I made these changes to my custom firmware build. I also tried only changing the EEPROM version, but it went back to bootlooping as usual, so there appears to be something wrong with motor_current_setting and tmc_sgt being present in settings.cpp. |
This comment was marked as off-topic.
This comment was marked as off-topic.
yes |
|
Please test it: |
Bootloop. Console output: |
Thanks, so I can't replicate the successful of here #1180 (comment) Maybe the bug is feature dependent and moves according to the use of the used EEPROM space |
|
It looks like something happened with the bootloader. I cant reflash to custom build or stock firmware. It's always "OFFICIAL BUILD: 20231224 - 14:00" |
Try with another SD card, format it. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
This firmware build should help us to know where the CRC was corrupted, please log the error messages for EEPROM read and EEPROM write without change any settings. |
After this firmware i cant flash to custom build or stock firmware. Always OFFICIAL BUILD: 20240108 - 14:18. Reflash only after bootloader flash. |
|
Excellent: So, now I need to analyze why the CRC is different. |
|
Any update to this? i suspect im running into the same issue with my compiled build but am not tech savvy enough to be useful for debugging |
i am also unable to reflash after using this firmware |
|
@dmenzie unfortunately, I my case the only thing what can help is reflashing with ST-Link. The bootloader area seems to be overwritten after flashing. Do you need help with this? |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@Arturchik29 yes please, any advice/guidance would be appreciated. I have an ST-link clone and/or an Arduino to get it done, but am unfamiliar with programming microcontrollers, id assume the process is similar to an older ender 3 (which I can find video documentation on how to do), but am unsure if there is anything specific to the stm32f4 boards that I need to be aware of |
|
Issue solved!, We just found that Creality implemented some kind of flag zone in the EEPROM for the Ender3S1 F4 bootloader, if that zone is written with non 0 values the bootloader refuses to flash a new firmware. That solves the mystery of why that printer sometimes refuses to update new firmware and only can be solved by using a ST-link device, also that solves the mystery about the CRC EEPROM corruption |
|
That also means we have even less space to work with. 😮💨 |
it is not a problem with the flash program memory is a matter of EEPROM memory |
|
With the new per-slot ABL 2.0 settings, are we at any risk of filling it up? |
UBL has its own EEPROM zone out of that flag zone. But normal firmware without UBL is affected. Ok that mystery also was solved. |
|
And we don't have room for UBL in the CVLM firmware without some other major sacrifice, correct? |
But don't worry, the solution is on the way, we are trying it here: https://t.me/ender3v2s1firmware/66444 of course if more people test the fixes we will able to release it soon. |
|
I could perhaps give it a try this evening. |
|
A PR MarlinFirmware/Marlin#26729 was posted in Marlin repository which solves this issue. |
That zone is used by some boot loaders to save flags that control the flashing at boot process. The exclusion zone should be defined in the **.INI** board environments that require it by: ```log -DEEPROM_EXCL_ZONE=100,200 ``` or in the board pin file by: ```c++ #define EEPROM_EXCL_ZONE 100,200 // Test a range or #define EEPROM_EXCL_ZONE 333 // Test a single byte ``` For example, in the Ender-3S1 F4: Marlin\src\pins\stm32f4\pins_CREALITY_V24S1_301F4.h: ```c++ #define EEPROM_EXCL_ZONE 919,926 // Test a range ``` ### Related Issues In the Ender-3 S1 with the STM32F401 SoC the range of exclusion is from 919 to 926. Even if the zone is filled with 0xFF values, the boot loader changes it when the printer is rebooted: ```log 0370: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0380: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0390: FF FF FF FF 00 FF FF FF FF FF FF FF FF 66 FF FF 03A0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 03B0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ``` If the zone is not excluded, the boot loader may not allow flashing new firmware and may also cause CRC EEPROM corruption. Perhaps related to: #125 #1180 MarlinFirmware/Marlin#26144
|
Seems to be resolved in the latest sources. |
|
For people with an Ender3S1F4 printer which refuses to flash new firmware, @trotus47 has prepared a G-code file which could help with the flash process, simply put the new firmware (in the folder STM32F4_UPDATE), this file in the SD card and select and click on it in the Media menu, then reboot the printer. ; Professional Firmware Configuration File
;=====================================================
C10 ; Mark as a configuration file
M117 Applying configuration
;-----------------------------------------------------
M86 S0 T3 E0 B0 ; Reset flag zone
M500 ; Save all settings
;-----------------------------------------------------
G4 S1 ; Wait a second
M300 P200 ; Beep
M117 Configuration Applied
;----------------------------------------------------- |
|
None of the S1 F4? or an specific bin file? |
I was following the topic, meaning that compiling from scratch the firmware with the "Fix Ender-3 S1F4 EEPROM exclusion zone" won't work. |
|
In our test board the 916 was the start of the EEPROM exclusion zone that was checked doing a EEPROM dump. If the zone is filled with 0xFF values, the boot loader changes it when the printer is rebooted: So maybe the zone changes depending on the bootloader version installed in the printer board. If more reports are obtained, the exclusion zone will have to be expanded. |
That zone is used by some boot loaders to save flags that control the flashing at boot process. The exclusion zone should be defined in the **.INI** board environments that require it by: ```log -DEEPROM_EXCL_ZONE=100,200 ``` or in the board pin file by: ```c++ #define EEPROM_EXCL_ZONE 100,200 // Test a range or #define EEPROM_EXCL_ZONE 333 // Test a single byte ``` For example, in the Ender-3S1 F4: Marlin\src\pins\stm32f4\pins_CREALITY_V24S1_301F4.h: ```c++ #define EEPROM_EXCL_ZONE 919,926 // Test a range ``` ### Related Issues In the Ender-3 S1 with the STM32F401 SoC the range of exclusion is from 919 to 926. Even if the zone is filled with 0xFF values, the boot loader changes it when the printer is rebooted: ```log 0370: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0380: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0390: FF FF FF FF 00 FF FF FF FF FF FF FF FF 66 FF FF 03A0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 03B0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ``` If the zone is not excluded, the boot loader may not allow flashing new firmware and may also cause CRC EEPROM corruption. Perhaps related to: mriscoc#125 mriscoc#1180 MarlinFirmware/Marlin#26144
|
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. |
mriscoc
added
bug: Fixed
Did you test with a precompiled firmware?
Yes, problem fixed. printer boots fine.
Bug Description
When compiling MRISCO Source from scratch, causes Ender 3 S1 to soft brick and bootloop.
However if i load the precompiled binary file from GIT repo "Ender3S1-F4-UBL-20231214.bin" it boots just fine.
Alternatively if i compile creality stock firmware from GIT using marlin vers 2.0.8.3 that also boots OK.
Bug Timeline
New, 2023 Release
Expected behavior
I expect the newly complied binary to boot successfully just the same as the precompiled binary provided from GIT
Actual behavior
printer hangs on Creality splash screen and seems to bootloop when viewing the COM port.
Steps to Reproduce
Version of Professional Firmware
2.1.3
Printer model
Creality Ender 3 S1, F4
Electronics
STM23F401RC
LCD/Controller
DWIN
Other add-ons
No response
Bed Leveling
ABL Bilinear mesh
Your Slicer
Cura
Host Software
OctoPrint
Additional information & file uploads
BuildLog.txt
The text was updated successfully, but these errors were encountered: