Summary
- New debugging functions & crash analysis tools
- A rare memory bug debugged and fixed
- Long-Press action fixed
- Move auto reporting out of the temperature ISR
- Uint8_t used consistently for the block buffer's index
- "Preheating to load" screen behavior fixed
- Message on boot while inserting SD card fixed
- Algorithm for reading SN in EEPROM improved
- Spanish translation fixed
- Firmware version parsing removed
- Prusa Connect & PrusaLink - beta testers wanted!
In this minor release, the primary focus was on improving the debugging capabilities and fixing potential and bugs in the firmware. The main motivation behind this effort was to catch very rare bugs exhibiting symptoms like memory corruption or a random mid-print crash.
New debugging functions & crash analysis tools
The "Dump memory" feature is a very important new debugging support tool. It allows you to store the RAM content into the xFlash memory for further issue/bug analysis, just like we have in the Buddy firmware for the MINI+. This procedure has proven vital for identifying the rare bug of “static memory overwritten”.
MK3, MK3S and MK3S+
This feature is now accessible from the printer’s Display menu Support-> Dump memory, which is the last command within the Support menu.
The dump command is also available during an active print, which allows the user to execute an actual Memory "Snapshot" during a critical status or misbehavior of the printer. You will find it under LCD Menu -> Support -> Dump memory display menu. Please note that the snapshot takes some time to finish, therefore we advise not to use this feature if you are not experiencing any problems - i.e. the printer will stop for a while to dump the memory.
Also, to allow for simpler usage of this function, we put it at the end of the support menu for now. If it was hidden somewhere deep, a user experiencing an issue may hot reach this option quickly.
When you have connected a serial device like Pronterface or Octoprint, you can use the following commands via the serial link:
- D20 - create memory dump on xFlash (same as LCD Menu -> Support -> Dump memory)
- D21 - download/print the memory dump via the serial link. This is the only way to get the Dump from the printer. Warning: please be aware not to connect the serial link during print as it can restart the printer and break the recent printing job
- D22 - clear the current memory dump in the printer
The crash dump to xFlash is active at any time, it is stored in xFlash and can be downloaded even after the system reboot until a new D22 command is sent to the printer.
MK2.5, MK2.5S and MK2.5S+
The MK2.5 series does not contain the xFlash, so the situation is different. The dump cannot be stored but it can be sent down to a serial link. In order to get the memory dump from the printer, there must be a serial link connection available prior to any dump download. In default, the LCD Menu -> Support -> Dump to serial and crash dump are disabled after printer restart. To get the dump the following process has to be followed and serial commands used:
- Connect the serial link to Printer. As the serial link connection restarts the Printer, it has to be done before any further activity.
- Using the D23 command from the serial link enables the crash dump by setting the crash dump flag and activates the LCD Menu -> Support-> Dump to serial display menu.
- D23 R command disables the crash dump and removes the LCD Menu -> Support-> Dump to serial display menu.
- The command D23 E - sends the Dump down to the serial link immediately and resets the printer.
- Command D20, D21, D22 are ignored.
- The Dump to serial command should be available even during print and should be found again under LCD Menu -> Support-> Dump to serial display menu.
Please note, that in this release the “Dump memory” function is currently not fully working on the MK2.5 series. After the memory Dump is successfully sent down to the serial link the printer is freezing during Booting and you can see the following or similar:
To resolve the situation at the current firmware build, push the HW reset button below the knob and the printer will restart. We are working on a workaround, this feature should be fully functional in the future firmware release. Should you find any other issues, please let us know.
A rare memory bug debugged and fixed
We have noticed several issues with unpredictable and non-replicable behavior like preheat menu loop when the printer was powered on with already loaded filament. Unpredictability and non-replicability made the root cause identification very hard. Recently we believe we found the major root cause. Its explanation is rather technical, but there’s really no other way to describe it.
The bug was not directly in our firmware, but we believe we ran into a bug in the link-time code generation stage of GCC 4.9.2 (bundled with PF-build-env-1.0.6.*) with optimization for size. The generated code could then partially overwrite the stack, which obviously resulted in random behavior. A workaround was found to avoid this bug by not allowing some functions to get inlined, even when they were used at one spot only.
We believe this is the main reason behind issues #3147, #3151, #3175 and probably others. We have verified that the code generation issue was also present in 3.9.3 already and probably in older FW versions as well. We have been able to track the problem down to FW 3.8.0, it may have been there even longer.
For more detailed technical description see please: #3202
However, since we haven't been able to reproduce ANY of those issues mentioned above in-house during our tests, we kindly ask the community for help. To help with tracing those malfunctions, you can use the debugging tool described at the very beginning of these release notes.
Please, report any of those potential issues you discover on GitHub and attach the Crash Dump file.
Long-Press action fixed
In the previous releases, the LCD knob "Long press" action was monitored and executed within the temperature control loop Interrupt Service Routine (ISR). This operation could under some circumstances destroy the menu buffer and create the menu itself inconsistently.
This change improves the printer reaction when the user is applying the "Long press" action (move Z etc. ). The main change is that the jog wheel "Long press" execution part has been moved to the main program loop. The temperature control loop is now exclusively dedicated to its generic task - temperature control.
Move auto reporting out of the temperature ISR
This change is similar to the Long-Press action described above. The code running in the temperature Interrupt Service Routine (ISR) needs to be fully reentrant, which is hard to keep for other than Temperature control tasks.
For this reason, the auto reporting (response to M155) is moved to the main processing loop. This can make the auto reporting slower or irregular but removes the reentrant restriction, which allows to use “printf_P” to serial port and to keep Temperature ISR only for temperature control.
For more information head to: #3180
Uint8_t used consistently for the block buffer's index
We have identified and fixed another potential problem in the planner’s block buffer. The index was sometimes computed as an int (2 bytes), sometimes as 1-byte uint8_t. On the AVR working with 2-byte integers, this is generally not an atomic operation, because it takes multiple instructions to perform. Since it has been possible, all indices of the block buffer are now referenced as 1-byte uint8_t.
"Preheating to load" screen behavior fixed
During the Load filament process, the printer was waiting for the preset temperature and displayed the "Preheating to load" message. When the user removed the SD card, the previous message was replaced by the message "Card removed" but the Preheating process still did not finish, so the lasting displayed message was not correct. Now after this and similar action the “Preheating to load" message is redrawn again which is the correct Process status Message.
Message on boot while inserting SD card fixed
When the user inserted the SD card during the booting process, the "Sorting files" message was presented twice on the display later followed by the correct "Print from SD menu" message. The issue has been reported on GitHub issue #3135 and clearly reproduced.
We have fixed the SD card handling while booting scenario, which corrected the double "Sorting files" message. Now the system works correctly.
Algorithm for reading SN in EEPROM improved
Another significant improvement is a Serial Number (SN) reading algorithm change from the 32u2 communication chip. When reading the SN, the code is expected to start with the standard "CZPX" prefix used for all Prusa printers worldwide. Unsuccessful attempts are repeated until a valid SN is read.
Spanish translation fixed
A tiny contribution from our community on improving wording in Spanish translation. Specifically for the text string: "Was filament unload successful?".
Firmware version parsing removed
This FW optimization has saved 936 bytes of Flash memory which is very important in the already critically occupied XFlash memory.
Prusa Connect & PrusaLink - beta testers wanted!
We are currently looking for enthusiastic and experienced owners of the Original Prusa MK3/MK3S/MK3S+ 3D printers, who will join us in the testing of our newest cloud-based printing service Prusa Connect.
The project is now in the beta stage and we would appreciate feedback from you. Selected beta testers will receive an RPi Zero W with pre-soldered GPIO pins together with step-by-step install instructions for the PrusaLink, access to Prusa Connect cloud service, and technical support. The next steps are the following: put your cloud-connected printer to work, run as many prints as you can and share any bugs and issues you find. Any suggestions and ideas are welcome!
Are you interested? Fill in the application form and once selected, we will get in touch with you.