[marlinBFT] Flashing failed, Unable to transfer firmware file to printer

[Simonlebucheron]

Hardware Setup
Creality V4.2.2, Ender3V2, octoprint, raspberrypi 3b1.2

Software setup
OctoPrint 1.8.1, octopi_version: 0.18.0
Experimented with different firmwares : marlin release 2.1, Marlin bugfix-2.1.x
VS code :
default_envs = STM32F103RE_creality_xfer or STM32F103RE_creality
Tested with commented and uncommented #define CUSTOM_FIRMWARE_UPLOAD

Describe the problem
Message "Flashing failed Unable to transfer firmware file to printer" when flashing with marlin BFT method.
The octoprint.log tell us : Exception: Cannot open file on client
What does it mean ?

Log Files
octoprint.log:
octoprint(5).log

plugin_firmwareupdater_console.log
Nothing in it (why ?)

Additional context
I tried different configurations over two days, different firmwares, and i finally make a clean install of octoprint 1.8.1 on a new sdcard but non results.
Since it is the only flashing method which seams to be working with de V4.2.2 creality board, I would love to have this feature so I would be happy to help figuring out a solution.

[benlye]

Can you try another client / browser?

[benlye]

Also, can you enable verbose BFT protocol logging and upload the resulting octoprint.log file? The console log is empty because this method doesn't run any external commands.

[Simonlebucheron]

Can you try another client / browser?

I just test with firefox, chrome and microsoft edge but with no results, that was you mean ?

Also, can you enable verbose BFT protocol logging and upload the resulting octoprint.log file? The console log is empty because this method doesn't run any external commands.

How should I do that ?

[benlye]

I just test with firefox, chrome and microsoft edge but with no results, that was you mean ?

Do you have a separate computer you can try from?

How should I do that ?

[Simonlebucheron]

Soory, I forgot I have seen verbose BTP protocol logging in the documentation and I already activate it earlier.
I attached a new full log after it clean the old one from octoprint :
octoprint(7).log

What is : 2022-07-05 16:56:26,512 - octoprint.plugins.firmwareupdater - INFO - Setting maximum upload size for /flash to 5243904 at the beginning of the log?

[Simonlebucheron]

Do you have a separate computer you can try from?

I tried from an another computer (windows 10 too), same thing in the log "Cannot open file on client"

[Simonlebucheron]

For information, I activated the serial.log from octoprint. There is no trace of the file exchange

When i normally switch on the printer and octoprint connect to it, il looks like:
2022-07-05 17:32:46,969 - Connected to: Serial<id=0x6a007390, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor

when i retry to update the firmware and the process lead to the disconnection/reconnection:
2022-07-05 17:34:16,842 - Connected to: Serial<id=0x635f7b30, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor

The only difference I see is the timeout but I don't think it matters.
you can find attached the log
serial(2).log

[benlye]

It's as if the file really doesn't exist on your Pi, or something (like permissions) is stopping OctoPi from reading it. I've never seen this before.

2022-07-05 16:56:26,512 - octoprint.plugins.firmwareupdater - INFO - Setting maximum upload size for /flash to 5243904

Is saying that they largest file the server will accept from the browser is 5,243,904 Bytes, or about 5MB. We can increase that but 5MB should be plenty. What is the size of the firmware file you're trying to upload?

[benlye]

Actually the error is misleading / badly worded. Cannot open file on client really seems to mean that the protocol cannot open the target file (I thought it meant the source file).

I can only guess that there is something in your running firmware which is causing the BFT protocol to fail. Either that or another OctoPrint plugun is interfering with the serial connection.

[benlye]

Another thought - I've got a Creality v4.2.2 board for testing. Do you have the bin file for the firmware that your printer is running? If you upload the file I could try loading it on my board to see what happens when I try to use BFT to load a new file to it.

[Simonlebucheron]

Here is my last firmware
firmware-20220705-120042.zip

In parallel, Ill try with different location of the file, like directly one the raspberry.

[Simonlebucheron]

In parallel, Ill try with different location of the file, like directly one the raspberry.

I do not know how to select a local file with the plugin, maybe it is not even possible ?
I tried several names, with no results.

Sould we suspect the network between the file and the raspberry ?

[benlye]

Here is my last firmware firmware-20220705-120042.zip

I can confirm that with this FW installed on the board I cannot use BFT to transfer any further FW updates, so the problem seems to be something in this image which is rendering the BFT protocol unusable.

What's interesting is that the code which is supposed to delete the previous FW file is also not working - the file remains on the SD card. Furthermore, no files can be removed from the SD card with the M30 command. It's as if the SD card is read-only.

end: M20
Recv: Begin file list
Recv: FOO.GCO 0
Recv: BOO~1.GCO 0
Recv: End file list
Recv: ok
[...]
Send: M30 FOO.GCO
Recv: Deletion failed, File: FOO.GCO.
Recv: ok

Compared with the same command on a firmware I compiled from the bugfix-2.0.x branch this morning:

Send: M20
Recv: Begin file list
Recv: FOO.GCO 0
Recv: BOO~1.GCO 0
Recv: End file list
Recv: ok
[...]
Send: M30 FOO.GCO
Recv: File deleted:FOO.GCO
Recv: ok

So I think your problem is in your firmware, but I don't know what is causing it. I noticed you have CUSTOM_FIRMWARE_UPLOAD enabled so I tried that too but it does not cause the same problem (at least not on its own).

If you compiled this firmware yourself you need to take a look at the settings you have changed and see if you can figure out where the problem is.

[Simonlebucheron]

Indeed, that is interesting, thank you for your investigation.

So I think your problem is in your firmware, but I don't know what is causing it. I noticed you have CUSTOM_FIRMWARE_UPLOAD enabled so I tried that too but it does not cause the same problem (at least not on its own).

It was just a test after reading some threads on the binary file transfer issues, I will disable it from now.

If you compiled this firmware yourself you need to take a look at the settings you have changed and see if you can figure out where the problem is.

Yes I have, with VScode but nothing fancy I think, I will look further in this way and try to compile the bugfix 2.0.x, but my primary goal was to update my printer from and old bugfix-2.0.x to 2.1 release.

By the way, in the documentation for marlin BFT flashing it refers only to bugfix-2.0.x branch, can you try compiling from your side with bugfix-2.1.x which is the new default branch, or 2.1.x ?

[benlye]

By the way, in the documentation for marlin BFT flashing it refers only to bugfix-2.0.x branch, can you try compiling from your side with bugfix-2.1.x which is the new default branch, or 2.1.x ?

Yes, I'm running bugfix-2.1.x on my own printer and BFT works fine. My board is a BTT SKR Turbo, but I'll try 2.1.x on the Creality board too when I get a chance.

[benlye]

I can confirm that firmware I just compiled from the current bugfix-2.1.x branch for my Creality v4.2.2 board also has this problem (the SD card seems to be read only - files cannot be deleted).

Firmware I just compiled from today's bugfix-2.1.x branch for my SKR Turbo does not have the problem - I can read and write the SD card.

So this looks like a bug or configuration issue in Marlin's bugfix-2.1.x branch which affects the Creality board (maybe others).

[benlye]

Seems like this is probably related to MarlinFirmware/Marlin#24422.

[Simonlebucheron]

I have just recompiled a fresh new FW from latest bugfix-2.0.x branch without any changes in configuration.h and configuration_adv.h except #define SDCARD_CONNECTION ONBOARD and #define BINARY_FILE_TRANSFER and BFT is not working (same error).

Compared with the same command on a firmware I compiled from the bugfix-2.0.x branch this morning:

Since you tested it this morning with the same board, I do not understand why it is not working for me. Any ideas ?
I will test an "old" 2.0.x bugfix branch.

[benlye]

My initial tests were with an older bugfix-2.0.x branch. Reading through the Marlin issue, it sounds like there is a 'new' bugfix-2.0.x since 2022-02-22, and builds up to this date might be OK.

I haven't been following Marlin development too closely so don't know what the story is with 'new' and 'old' bugfix-2.0.x but I did see when I tried to update one of my branches that there were a lot of changes at some point in the past few months. It sounds like there was a complete SD IO rewrite somewhere in there.

[Simonlebucheron]

I confirm:
BFT doesn't seam to work with Marlin 2.0.9.4
BFT work perfectly with Marlin 2.0.9.3

I am not sure what to look to find the cause, what are your suggestions ?

[Simonlebucheron]

Modification like that on sdio.h and sdio.cpp could impact function of the firmware updater plugin ?

[benlye]

I don't know. I think you either need to comment on the Marlin SD Card problem issue I linked above or create your own issue on the Marlin repository. Remember that the root cause here seems to be that we can't write to the SD card (to create new files or delete old ones). The firmware updater plugin is impacted because SD card IO operations are failing.

Commenting on the existing issue might be the way to go because this issue (which sounds pretty similar to what we're seeing) was closed as a duplicate of MarlinFirmware/Marlin#24422.

[Simonlebucheron]

Done here ;)
Waiting to find a solution maybe you could update the documentation with a warning for the creality V4.2.2 owners to use only Marlin 2.0.9.3 ?

[mriscoc]

I arrived here later, I also had the same error with the latest Marlin Bugfix 2.1, maybe because of the refactoring of the SDIO module.

[Simonlebucheron]

Hum, I tried the again with the new bugfix 2.1.x but BFT failed with the same error, no file written on the sd card... I will try later after getting some sleep...

[mriscoc]

For an Ender3V2 with 422 (STM32F1) latest SDIO commit in Bugfix solves the issue.

[Simonlebucheron]

It is working, I think it was a mess in my VStudio files. Thank you for all @benlye , this plugin is very useful and time saving.

[github-actions]

This issue has been automatically locked because there was no further activity after it was closed. Please open a new issue for any related problems.