[BUG] Latest Release boot loops on start-up #25852
Comments
|
I've got similar. Gone back to 2.0.x |
|
I have the same issue, but I managed to enter the menu by clicking the encoder button during the boot. The printer then operates normally until it automatically goes to the main screen and the boot loop starts again. |
So the issue occurs for you in 2.1.0, 2.1.1, and 2.1.2 as well? |
|
I did recently patch ProUI to fix a watchdog reset due to a long Boot Screen Timeout. Do you still see the problem with today's bugfix-2.1.x code? If so, we should try to determine the exact commit that introduced the issue. I use the Trigorilla on a Chiron with a regular GLCD and have not experienced this issue. |
|
I've managed to run 2.1.2.1 successfully. The problem was about faulty configuration file I've found here for my printer. I've took the default configuration file, adapted it line by line and now everything works as it should. |
I had no problems with 2.1.2. The issue started with 2.1.2.1 and its bugfixes. I am using the /delta/anycubic/predator example configurations posted with the initial 2.1.2.1 release, and have also tried the latest configurations. As of May 31, 2023 at 9:45 EST in the US, the problem still exists on the latest bugfix. Also, folks need to be careful here. A Trigorilla (Chiron) board is NOT a Trigorilla Pro (Predator) board. Completely different animals. |
|
Just tried the latest bugfix and example configs for delta/anycubic/predator. Problem still exists June 1, 2023. No display, continuous boot loop. 2.1.2 from May 15 is fine. |
|
What is the solution?? Isn't it necessary to update to the latest version of marlin? |
|
@andystoc , that's the whole point of this bug report. The latest 2.1.2.1 bugfix IS the very latest Marlin, and it does not work on the Anycubic Predator. Marlin 2.1.2 from May 15 works well. Something broke between 2.1.2 and 2.1.2.1. |
|
my printer is an artillery x1 with electronic board skr 2 F429 |
|
I get the same with the current bugfix building for a I've enabled Config Files |
@SwiftNick: Please attach your configs. |
Done. |
|
@SwiftNick Not in the circuit diagram... not that I can see (I could be blind) try disabling |
Yes it's an add on board. |
|
Good day, I am going to try in my skr 2 to see if it is solved by disabling the same. |
|
This has worked with 2.1.x bugfix |
|
Maybe 🚸 Improve EEPROM validation (#25860) broke some EEPROM types? [cron] Bump distribution date (2023-05-20) is the prior commit, so please test with this .ZIP download and report back. Here's 🚸 Improve EEPROM validation (#25860), so please test with this .ZIP download and report back. I have a BTT I2C EEPROM module around here somewhere that I'll track down and see if I can do a |
|
Both versions work ok. So I went back to the latest bugfix again. It still goes wrong, Still using the latest bugfix, I removed the EEPROM settings, disabled EEPROM_SETTINGS and PRINTCOUNTER Still get boot loops. |
These boot loop on the Trigorilla Pro. Just to be clear, there were no issues with 2.1.2 and its bugfixes. Issues started on 2.1.2.1 and subsequent bugfixes, May 16. |
|
Using @SwiftNick's configs, I was able to reproduce the bootloop on an SKR Pro 1.1 with a RobotDny AT24C256 I2C EEPROM and BTT TFT70 with the latest I also enabled Using "Marlin Mode" on the TFT, everything looked/worked fine. I could change settings & save them, restart the motherboard and verified that they were correctly saved. Removing the I2C EEPROM, saved settings would disappear as expected. I switched over to "Touch Mode" and noticed it wasn't connected due to an incorrect baud rate on the TFT. Once I changed the baud rate, the bootlooping started as soon as it would connect. Connecting the board via USB cable also causes bootloops. ...which sounds a lot like #26030. The board doesn't bootloop if I disable the second serial port/leave the TFT's serial cable disconnected or leave the USB cable disconnected. I'll test on some other machines & get started on some |
|
My other printers are now bootlooping on USB connect with current |
The latest (July 1, 2023) bugfix and configuration files still continuously re-boot with no display on my Anycubic Predator. However, during compile there are two warnings, which are new as of today: error:
Marlin\src\feature\runout.cpp: In function 'void event_filament_runout(uint8_t)':
Marlin\src\feature\runout.cpp:104:14: warning: unused variable 'park_or_pause' [-Wunused-variable]
104 | const bool park_or_pause = (false
| ^~~~~~~~~~~~~
Compiling .pio\build\trigorilla_pro\src\src\gcode\config\M200-M205.cpp.o
Compiling .pio\build\trigorilla_pro\src\src\gcode\config\M220.cpp.o
Compiling .pio\build\trigorilla_pro\src\src\gcode\config\M221.cpp.o
Compiling .pio\build\trigorilla_pro\src\src\gcode\config\M301.cpp.o
Compiling .pio\build\trigorilla_pro\src\src\gcode\config\M302.cpp.o
Compiling .pio\build\trigorilla_pro\src\src\gcode\config\M304.cpp.o
Compiling .pio\build\trigorilla_pro\src\src\gcode\config\M92.cpp.o
In file included from C:\Users\rquin\.platformio\packages\framework-arduinoststm32\cores\arduino/WString.h:29,
from C:\Users\rquin\.platformio\packages\framework-arduinoststm32\cores\arduino/Print.h:27,
from C:\Users\rquin\.platformio\packages\framework-arduinoststm32\cores\arduino/Stream.h:26,
from C:\Users\rquin\.platformio\packages\framework-arduinoststm32\cores\arduino/HardwareSerial.h:29,
from C:\Users\rquin\.platformio\packages\framework-arduinoststm32\cores\arduino/WSerial.h:5,
from C:\Users\rquin\.platformio\packages\framework-arduinoststm32\cores\arduino/wiring.h:47,
from C:\Users\rquin\.platformio\packages\framework-arduinoststm32\cores\arduino/Arduino.h:36,
from c:\temp\marlin-bugfix-2.1.x\marlin\src\hal\shared\marduino.h:36,
from c:\temp\marlin-bugfix-2.1.x\marlin\src\hal\stm32\hal.h:28,
from c:\temp\marlin-bugfix-2.1.x\marlin\src\hal\hal.h:30,
Compiling .pio\build\trigorilla_pro\src\src\gcode\control\M108_M112_M410.cpp.o
from Marlin\src\gcode\calibrate\../../inc/MarlinConfig.h:33,
from Marlin\src\gcode\calibrate\G33.cpp:23:
In member function 'MString<SIZE, SAFE>& MString<SIZE, SAFE>::set_P(const char*) [with int SIZE = 14; bool SAFE = true]',
inlined from 'MString<SIZE, SAFE>& MString<SIZE, SAFE>::set(FSTR_P) [with int SIZE = 14; bool SAFE = true]' at c:\temp\marlin-bugfix-2.1.x\marlin\src\core\mstring.h:114:65,
Compiling .pio\build\trigorilla_pro\src\src\gcode\control\M111.cpp.o
inlined from 'SString<SIZE>& SString<SIZE>::set(const T&) [with T = const __FlashStringHelper*; int SIZE = 14]' at c:\temp\marlin-bugfix-2.1.x\marlin\src\core\serial.h:281:40,
inlined from 'static void GcodeSuite::G33()' at Marlin\src\gcode\calibrate\G33.cpp:656:38:
C:\Users\rquin\.platformio\packages\framework-arduinoststm32\cores\arduino/avr/pgmspace.h:65:35: warning: 'char* strncpy(char*, const char*, size_t)' output truncated before terminating nul copying 14 bytes from a string of the same length [-Wstringop-truncation]
65 | #define strncpy_P(a, b, n) strncpy((a), (b), (n))
Compiling .pio\build\trigorilla_pro\src\src\gcode\control\M120_M121.cpp.o
| ~~~~~~~^~~~~~~~~~~~~~~
c:\temp\marlin-bugfix-2.1.x\marlin\src\core\mstring.h:113:45: note: in expansion of macro 'strncpy_P'
Compiling .pio\build\trigorilla_pro\src\src\gcode\control\M17_M18_M84.cpp.o
113 | MString& set_P(PGM_P const s) { strncpy_P(str, s, SIZE); debug(F("pstring")); return *this; }
| ^~~~~~~~~
Marlin\src\gcode\calibrate\G33.cpp: In static member function 'static void GcodeSuite::G33()':
Marlin\src\gcode\calibrate\G33.cpp:654:22: warning: 'snprintf' output truncated before the last format character [-Wformat-truncation=]
654 | msg.setf(F("Iteration : %02i"), (unsigned int)iterations);
C:\Users\rquin\.platformio\packages\framework-arduinoststm32\cores\arduino/avr/pgmspace.h:30:20: note: in definition of macro 'PSTR'
30 | #define PSTR(str) (str)
| ^~~
Marlin\src\gcode\calibrate\G33.cpp:654:20: note: in expansion of macro 'F'
654 | msg.setf(F("Iteration : %02i"), (unsigned int)iterations);
| ^
C:\Users\rquin\.platformio\packages\framework-arduinoststm32\cores\arduino/avr/pgmspace.h:74:39: note: 'snprintf' output between 15 and 24 bytes into a destination of size 14
74 | #define snprintf_P(s, n, ...) snprintf((s), (n), __VA_ARGS__)
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
c:\temp\marlin-bugfix-2.1.x\marlin\src\core\serial.h:272:52: note: in expansion of macro 'snprintf_P'
272 | SString& setf_P(PGM_P const fmt, Args... more) { snprintf_P(str, SIZE, fmt, more...); debug(F("setf_P")); return *this; }
| ^~~~~~~~~~ |
|
Latest bugfix (July 19, 2023) still has blank display and continuously boot loops on start-up. However, the compile time warning has changed to: |
|
change |
Thanks @ellensp . That fixed the warning for a smooth compile. However, the screen is still blank, and the machine still continuously re-boots every 3 seconds with todays bugfix and example configuration. As noted above, release 2.1.2 worked well, but bugfix 2.1.2.1 released May 17 started the screen and boot loop issue. |
|
Have we narrowed down the exact commit using The strategy is to find a commit from some point in the "distant" past where the feature works. Then, test a commit from halfway between that date and today…. And then you keep going to the commit half-way in between your "known to work" commit and your "known to be broken" commit until you find the exact commit where it broke. If you started from a point 256 commits in the past, it would take no more than 8 tests to find the exact commit that broke it. Commit-points can be downloaded by going to the page https://github.com/MarlinFirmware/Marlin/commits/bugfix-2.1.x and clicking on the "<>" button to go to that point in time, then downloading the ZIP file from that page. Of course, this can take a lot of downloading, so it's always easier if you use something like GitHub Desktop to go to commits from a checked out local copy of Marlin. Another challenge is getting the same config files to work with different points in time, so it's best to turn off all optional features during testing. Once we know the exact commit then it should hopefully be trivial to fix. If someone knows of a common board that I'm likely to have in my random collection, I can also make the attempt. The original report was a Trigorilla Pro, which I don't have on hand. But I do have a lot of STM32 boards, so one of them is bound to reproduce the issue. Also, is it related to a specific display, or will any display do? Another helpful thing is to enable Did anyone try disabling |
|
Commit 2de2185 of June 2, 2023 compiles and functions on the printer. Attached are the configs, which are basically the example configurations for the Anycubic Predator from that date. Commit 32be406 from the same date also compiles and loads, but the display is scrambled. Same configs. Commits immediately after that do NOT compile, and need a different set of config files, but NOT the config files from later bugfixes. Later bugfixes will compile with their associated configs, but the display is completely blank, and the machine boot loops continuously. So there are at least three (3) different configurations for this printer, and I have yet to discover a means of keeping track of which configuration goes with each commit. |
That is expected since you have to adjust/port your configs as you traverse the commit history.
That's why I mentioned having to manually port your config with minimal settings to make this process easier.
As for commits that fall in that range, bc38512 stands out as a possible cause of your scrambled screen. To track down the boot loops, you'll need to port your config through the commits, resolving any conflicts/changes to test further. |
|
Just to recap: Using the same config files, the earlier commit 2de2185, from the same date, seems to work fine. So, I decided to work backwards, since the intent is to find the commit that causes a blank screen and boot looping.
details:
In file included from Marlin\src\module\../inc/../HAL/../HAL/STM32/HAL.h:28,
from Marlin\src\module\../inc/../HAL/HAL.h:30,
from Marlin\src\module\../inc/MarlinConfig.h:33,
from Marlin\src\module\../MarlinCore.h:24,
from Marlin\src\module\planner.h:33,
from Marlin\src\module\planner.cpp:68:
Marlin\src\module\planner.cpp: In static member function 'static void Planner::reverse_pass_kernel(block_t*, const block_t*, const_float_t)':
Marlin\src\module\planner.cpp:1010:138: error: 'MINIMUM_PLANNER_SPEED' was not declared in this scope
1010 | const float next_entry_speed_sqr = next ? next->entry_speed_sqr : _MAX(TERN0(HINTS_SAFE_EXIT_SPEED, safe_exit_speed_sqr), sq(float(MINIMUM_PLANNER_SPEED))),
| ^~~~~~~~~~~~~~~~~~~~~
Marlin\src\module\../inc/../HAL/../HAL/STM32/../shared/Marduino.h:51:17: note: in definition of macro 'sq'
51 | #define sq(x) ((x)*(x))
| ^
Marlin\src\module\planner.cpp:1014:39: error: 'new_entry_speed_sqr' was not declared in this scope; did you mean 'next_entry_speed_sqr'?
1014 | if (current->entry_speed_sqr != new_entry_speed_sqr) {
| ^~~~~~~~~~~~~~~~~~~
| next_entry_speed_sqr
Marlin\src\module\planner.cpp:1010:19: warning: unused variable 'next_entry_speed_sqr' [-Wunused-variable]
1010 | const float next_entry_speed_sqr = next ? next->entry_speed_sqr : _MAX(TERN0(HINTS_SAFE_EXIT_SPEED, safe_exit_speed_sqr), sq(float(MINIMUM_PLANNER_SPEED))),
| ^~~~~~~~~~~~~~~~~~~~
Marlin\src\module\planner.cpp: In static member function 'static void Planner::recalculate_trapezoids(const_float_t)':
Marlin\src\module\planner.cpp:1247:92: error: 'MINIMUM_PLANNER_SPEED' was not declared in this scope
1247 | next_entry_speed = _MAX(TERN0(HINTS_SAFE_EXIT_SPEED, SQRT(safe_exit_speed_sqr)), float(MINIMUM_PLANNER_SPEED));
| ^~~~~~~~~~~~~~~~~~~~~
In file included from Marlin\src\module\../inc/../HAL/../HAL/STM32/HAL.h:28,
from Marlin\src\module\../inc/../HAL/HAL.h:30,
from Marlin\src\module\../inc/MarlinConfig.h:33,
from Marlin\src\module\../MarlinCore.h:24,
from Marlin\src\module\planner.h:33,
from Marlin\src\module\planner.cpp:68:
Marlin\src\module\planner.cpp: In static member function 'static bool Planner::_populate_block(block_t*, const abce_long_t&, const xyze_pos_t&, feedRate_t, uint8_t, const PlannerHints&)':
Marlin\src\module\planner.cpp:2853:88: error: 'MINIMUM_PLANNER_SPEED' was not declared in this scope
2853 | const float v_allowable_sqr = max_allowable_speed_sqr(-block->acceleration, sq(float(MINIMUM_PLANNER_SPEED)), block->millimeters);
| ^~~~~~~~~~~~~~~~~~~~~
Marlin\src\module\../inc/../HAL/../HAL/STM32/../shared/Marduino.h:51:17: note: in definition of macro 'sq'
51 | #define sq(x) ((x)*(x))
| ^
Compiling .pio\build\trigorilla_pro\src\src\sd\Sd2Card.cpp.o
Compiling .pio\build\trigorilla_pro\src\src\sd\SdBaseFile.cpp.o
*** [.pio\build\trigorilla_pro\src\src\module\planner.cpp.o] Error 1
Obviously there is a set of configuration files that will allow commits EARLIER than c666b49 to compile, so that I can continue the binary search for which commit caused the blank display and re-boot issue. I do not know how to find, or create, those configuration files for the Anycubic Predator. |
|
Instead of worrying about testing configs from the Configurations repo, enable the bare minimum in each commit's configs to test if the board bootloops: #define MOTHERBOARD BOARD_TRIGORILLA_PRO
#define SERIAL_PORT 1
#define ANYCUBIC_TFT35
#define TFT_CLASSIC_UI |
@thisiskeithb , I feel like I am repeating myself. All of what you have referenced is true. It does not matter whether the display is classic or color. The printer still boot loops. I say again, I am using the configuration files associated with each release, but I do not know how to find, or generate, configuration files for a particular printer for a particular commit. Old configs work for commits around June 2. New configs compile for recent commits, but boot loop. Somewhere in between, a change was made that causes the boot loop, but I do not know how to find, or create, the config files that will allow me to successfully compile firmware.bin files that I can use to do further binary searches. A binary search is impossible if I cannot create a usable firmware.bin file. I need config files for the Anycubic Predator that will yield compiled firmware.bin files for commits between June 2 2023 and October 27, 2023. |
You don't need to find a matching config or a full/complete config for this machine to test bootlooping. You just need to enable the bare minimum options in each download & observe if Marlin boots: #define MOTHERBOARD BOARD_TRIGORILLA_PRO
#define SERIAL_PORT 1
#define ANYCUBIC_TFT35
#define TFT_CLASSIC_UIThe overall idea here is to download the .zip for each Starting with June, 2023:
|
|
@thisiskeithb , many thanks! The issue is in the example/delta/Anycubic/Predator/configuration.h file. Using that file causes a blank display and continuous re-booting. Using a bare bones configuration.h, even with the latest bugfix, boots and displays fine. I am currently doing file compares with WinMerge between the configuration.h versions to hopefully find the cause. I do know at this point that it's nothing as simple as mis-applied serial ports or the like. |
|
The repetitive boot loop is caused by enabling "#define SDSUPPORT" in configuration.h |
Now you add that option to the list of features that need to be enabled and retest using the process outlined in #25852 (comment) |
Keith, how did I know you were going to say that? |
thisiskeithb
added
Bug: Potential ?
Needs: More Data
|
Well, this is aggravating! If you download the configs for that release, under examples/delta/Anycubic/Predator, starting at line 2474 in configuration.h: BOTH of those lines have to be enabled for the printer to boot successfully, and since they are not both available in the basic configuration.h file, it can never function at all. And obviously a binary search is a waste of time, because you can't enable a function that isn't there. I only found this because I had old but functional copies of the config files, and the difference showed up in a winmerge comparison. Not fun trying to determine which differences made a difference. I may be near the 10,000 cycle limit on my EEPROM ;-) |
|
You should be using |
Cool. And how does one do that when the configuration.h file does not contain the define needed to make the problem go away? In other words, the basic configuration.h file included with every commit is NOT the same as the configuration.h files found in the example configurations, with appropriate toggles and data. I thought they were, and so did you, but there is no "#define SDIO_SUPPORT" toggle available in ANY basic config that I can find. And without that define, and whatever it does, the machine will boot loop. In other, other words, somewhere #define SDIO_SUPPORT was inserted into the example configurations, but NOT the configurations released with each commit. Is it unique to the Anycubic Predator? |
Please read through my previous comment again: #25852 (comment). You don't need to find a matching config or a full/complete config for this machine to test bootlooping. You just need to enable the bare minimum options in each download & observe if Marlin boots. |
But that's the point. The configuration.h in the Marlin folder of each bugfix does not include SDIO_SUPPORT and SDSUPPORT. |
That's because it's typically handled in the pins file, but I see some configs have added it as well. Simply define it in your config manually and continue testing. |
@thisiskeithb , I would call this a two part bug:
If both of those changes are made to today's bugfix, it works, at least with Color_UI. |
|
SDIO_SUPPORT never was in default configs. Actual bug is absence of SDIO_SUPPORT in pins.h. Or course, it must be removed from affected configs as well. |
But SDIO_SUPPORT WAS in some example configurations, which is what made this all so confusing. At least to me. Having two different files of the same name is...problematic. Trying to track down an issue that cannot be toggled in configuration.h is not easy. |
|
|
|
Since |
github-actions
bot
removed
Bug: Potential ?
Needs: More Data
|
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.1.xcode?Yes, and the problem still exists.
Bug Description
Using the latest bugfix and configuration files, the printer displays a black screen and continuously re-boots with Classic UI. With Color UI, the screen is dimly lit, and also continuously re-boots.
Bug Timeline
New with 2.1.2.1 and recent bug fixes.
Expected behavior
Clean boot and visible display.
Actual behavior
Missing display and continuous re-boot.
Steps to Reproduce
Version of Marlin Firmware
Latest Bugfix 2.1.2.1
Printer model
Anycubic Predator
Electronics
Stock Trigorilla Pro (STM32F103)
Add-ons
No response
Bed Leveling
None
Your Slicer
None
Host Software
None
Don't forget to include
Configuration.handConfiguration_adv.h.Additional information & file uploads
Configuration.zip
The text was updated successfully, but these errors were encountered: