Summary
- Upgraded USB drivers
- Upgraded Newlib library
- FatFs library upgrade
- Saving of self-test results
- Fixed bugs
This is the final release of firmware 4.3.2. This changelog is a summary of the previous releases (beta1, RC1 and RC2). The main focus is on bug fixes related to the USB Flash drivers and performance-related optimizations.
Upgraded USB drivers
We’re constantly updating and optimizing the MINI+ firmware to further improve its performance and reliability. In this release, the developers focused on the USB driver responsible for handling all the data transfers from the connected USB flash drive (e.g., mounting drives, reading G-codes, ...). We received several reports that certain USB drives weren't working properly.
Together with the chipset manufacturer (STM company), developers have tested and deployed a new version of the USB driver. As a result, the Buddy board should now be able to communicate even with the problematic USB drives. Previously, when the drive wasn't properly recognized by the printer, the only option was to reinsert it. This is not necessary anymore, the system will handle it on its own.
Note that these fixes do not address a scenario when certain USB drives are not correctly detected by the bootloader. For example, while attempting to flash a new firmware.
Upgraded Newlib library
This firmware release brings an important upgrade to the Newlib library. The standard library is replaced with a more optimized Newlib-nano version. Also, the standard “printf” family functions are replaced with a different implementation.
This change results in several improvements and memory savings. Compared to the previous firmware 4.3.1:
- 98 kB of FLASH memory is saved
- 4 kB of RAM is saved (3 kB on heap/static allocations, 1 kB on stack)
- makes the printf() family functions fully reentrant and thread-safe (the previous implementation did not allow formatting of floats in ISRs)
Multiple tests revealed no negative effects related to these changes in the MINI+ firmware project. The measurements of RAM usage were done with release builds with metrics enabled while printing.
FatFs library upgrade
This build brings an upgrade of the FatFs library, which is supposed to fix synchronization issues of accessing the file system.
FatFs library has been upgraded from R0.12c to the latest version of R0.14b. The most important change is the fix of synchronization issues related to accessing the FAT file system. Please see the release notes of the FatFs library for details, where the synchronization fix is also discussed.
This also fixed several reported situations of BSOD after the removal of the USB drive from the MINI and MINI+.
Moreover, to improve the quality of testing of the USB drivers and file system fixes, we designed an automated device that simulates various edge cases while inserting and/or removing a USB drive. The testing device helped us to verify that the fix works as expected.
Saving of self-test results
The upgrade of the FatFs library also brings back the possibility of saving results of self-tests onto the USB drive (if present), which has been removed in previous versions due to random file system-related problems.
If you intend to use this feature, make sure there is a USB flash drive (FAT32) connected to the printer before the self-test is performed. Once the test is finished, a log file is saved onto the flash drive. Examples of use are provided in the release notes for firmware 4.3.0-RC1
Fixed bugs
Filament runout during serial print
When the print has been previously initiated from the serial line (e.g., OctoPrint) and a filament runout occurred, the printer did not react accordingly and the Change filament (M600) sequence was not initiated. Now, this behavior is fixed and even when the print is initiated by the serial interface, the Filament runout initiates the local Change filament sequence on the printer.
Extra head movements after the print ends
In rare cases, when the printer finishes the print, the print head performs additional random movements (repeated mesh bed leveling, additional purge line, etc.). From the reports, it seemed that this bug first occurred in firmware 4.1.0.
The developers have identified the issue caused by a long comment line in the G-code file (generated by PrusaSlicer merging all custom codes into one comment line), which is longer than the expected 95 characters. The characters exceeding the number 95 in this line were incorrectly parsed - text starting with the 96th character has been analyzed as a part of actual G-Code. In some cases, it may have contained G-Code commands, which have been interpreted and executed. The analysis was complicated due to users adding different Custom codes.
All concerned cases issued in Github are fixed now:
#864
#733