Bootloader not getting updated

[MinnesotaMean]

I don't want to open a bug report because it may not officially be a bug. However, I am unable to update the bootloader to anything above 1.0.0. Are there any official .bbf's that update to 1.1.1 or 1.0.1?

I've tried so many combinations and custom builds but no luck getting the bootloader up to the 2.0.2 that I need to use esp's.

Thank you!

[murk-sy]

I believe the next release - 4.4.0 - will have bootloader updating, guessing mostly on a few commits I've seen. As far as official releases go, I don't believe there's any way (or even reason) to update it yet. This is assuming you aren't compiling code yourself.

[MinnesotaMean]

I believe the next release - 4.4.0 - will have bootloader updating, guessing mostly on a few commits I've seen. As far as official releases go, I don't believe there's any way (or even reason) to update it yet. This is assuming you aren't compiling code yourself.

Yes, I understand that 4.4 requires 2.0.2 bootloader. The new v2 bbf and old v1 bbf's were not working with the code I compiled. I was able to manually flash v2.0.2 using DFU but get a boot loop when flashing any firmware that isn't 4.3.4.

Basically at the mercy of the Prusa dev team to finally release v4.4 or 4.4-rc.

[CarlosGS]

This https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/2155#issuecomment-1149491278 gives some insight into flashing the new version. It seems we need to place at the root of the USB both "build/products/mini_release_boot.bbf" and "build/products/mini_release_boot_update_pre_4.4.bbf" (manually compiled with python utils/build.py --generate-bbf). Once those are at the USB root, then following the normal update process should update the bootloader as well. Haven't tried it though. Looking forward to the official release!

[MinnesotaMean]

This #2155 (comment) gives some insight into flashing the new version. It seems we need to place at the root of the USB both "build/products/mini_release_boot.bbf" and "build/products/mini_release_boot_update_pre_4.4.bbf" (manually compiled with python utils/build.py --generate-bbf). Once those are at the USB root, then following the normal update process should update the bootloader as well. Haven't tried it though. Looking forward to the official release!

Correct, the pre4.4 bbf is their "legacy" v1 bbf and the normal release_boot.bbf is their new v2 bbf. Currently, if you compile a build off the master branch or off the 4.4 release branch, I get bootlooping, even with an updated 2.0.2 bootloader and even with both bbf's on the root of the usb drive

[CarlosGS]

You are right, flashing the current version produces a white screen. A bit scary, so thank you for the heads up :) Fortunately the bootloader is still 1.0.0 working OK, and it is possible to reflash easily.

Not sure how to debug this, I'd also love to help make the upgrade process more robust.

[CarlosGS]

Found the problem! At the setup of the external flash chip, the code is checking for a specific manufacturer ID. When the memory chip has a different manufacturer, this yields a white screen without any message, unfortunately causing a brick.

@MinnesotaMean you need to replace this line with return ((w25x_devid == DEVID) || (w25x_devid == DEVID_NEW));

I'd strongly recommend to move the MFRID check to later in the code, where it is possible to properly inform the user of the situation while keeping a working machine. The current implementation would brick their printers when upgrading to 4.4.0+ :confused:

[MinnesotaMean]

Found the problem! At the setup of the external flash chip, the code is checking for a specific manufacturer ID. When the memory chip has a different manufacturer, this yields a white screen without any message, unfortunately causing a brick.

@MinnesotaMean you need to replace this line with return ((w25x_devid == DEVID) || (w25x_devid == DEVID_NEW));

I'd strongly recommend to move the MFRID check to later in the code, where it is possible to properly inform the user of the situation while keeping a working machine. The current implementation would brick their printers when upgrading to 4.4.0+ 😕

You are fantastic!! I will test this out on Monday. I do have a few cloned buddy boards due to cost and lead time. Thank you so much for your deep dive into locating the problem for me.

[CarlosGS]

Oh! it seems this was introduced two years ago, and has simply shown up now the memory chip is being used :) Will submit a PR to fix it. Thank you for reporting as it helped to pinpoint the issue!

[Prusa-Support]

Hello. I can confirm that the bootloader will be possible to be updated via firmware in the future. Until then, if you are interested in firmware 4.4.0 and ESP WiFi module testing, building the firmware is at your risk. You can refer to this guidepost https://github.com/prusa3d/Prusa-Firmware-Buddy/tree/master/doc/ESP and pull request #1751.

While the discussion goes on, please consider closing the issue if you think that your question was addressed adequately.

Michele Moramarco Prusa Research

[CarlosGS]

@Prusa-Support Hi! We found the root cause of this issue and made PR https://github.com/prusa3d/Prusa-Firmware-Buddy/pull/2203, it would be resolved when that fix is merged.

Let's keep this open until it is actually resolved, I don't want 4.4.0+ to brick any board :+1:

[github-actions[bot]]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

[thisiskeithb]

PR #2203 is still pending, but it needs to be rebased/updated to current code and tested.