BTT SKR1.4 Turbo not flashing, failing to umount at start of process

[parsko41]

Hardware Setup SKR1.4 Turbo Octoprint 1.5.2 Octopi 0.17.0 Marlin Bugfix2.0 (all are the latest versions, and this whole setup is days old)

Describe the problem Hi Ben, I figured I would start a new issue. Seems these boards are causing a headache for this plugin...

I am failing to umount at the beginning of the update process.

Log Files I'm not sure I'm logging correctly... octoprint (8).log

Additional context I'd like to reference my comment in another thread: https://github.com/OctoPrint/OctoPrint-FirmwareUpdater/issues/149

I have gone through the FirmwareUpdater procedure a few times, and I get no changes. Everything seems to point to this being on the Pi side, I think. When I Putty into my Octopi and perform a "df -h" command, I do not see "USB0". This continues to baffle me, despite following your procedure exactly.

I have enabled SDCARD_CONNECTION LCD as well as SDCARD_CONNECTION BOARD, but neither work. I have also taken care of SD_IGNORE_AT_STARTUP as well.

I have included my config files via ZIP. Maybe I have a setting wrong in there?

CONFIG_FILES.zip

Please and thank you. This plugin is certainly awesome and amazing when working. I have used it the past month or two with great success on my MEGA2560/RAMPS1.6 setup.

-Parsko

[benlye]

Your printer fails to unmount the SD card but doesn't say why:

2020-12-28 16:58:58,026 - octoprint.plugins.firmwareupdater - INFO - Unmounting SD card: 'sudo umount /media/usb'
2020-12-28 16:58:58,186 - octoprint.plugins.firmwareupdater - ERROR - Error executing unmount command 'sudo umount /media/usb'

What happens if you run this command in the shell on the Pi?

sudo umount /media/usb

Is /media/usb even getting mounted at all? You need to figure that out before you can flash it, and that is beyond what I can help with - I don't have this board.

[parsko41]

umount: /media/usb: not mounted

I'm not really sure myself. I wonder if it's in the Marlin settings. Isn't this covered in your procedure? I'll do a bit more research.

I just got done building a FAN board out of a TIP102, and that WORKED! Now I can toggle an external fan as well as have the temperature controlled fan for my hotend. Playing with that required a bunch of SD card back and forth. Can't wait to solve this one so I don't have to shuffle.

Your procedure covers the PI side of the settings, and does not know what goes on on the peripherial (SKR) side of things, right?

Thanks again Ben! I'll get there.

[benlye]

You're going to have to figure out the magic combination of firmware options and mounting commands. There are details that have worked for other people in the other BTT SKR 1.4 issues, but there's not a lot I can do to help.

The plugin relies on the Pi having the SD card mounted and you'll need to figure that part out.

[XylenC4]

Attached you can find my Marlin-2.0.7.2 SKR 1.4 TURBO Configuration.

I'll had the same issue "not flashing, failing to umount at start of process". I'll re-installed my octopi with the latest image and still the issue was present. After reading carefully the Wiki I'll noticed the new? chapter "LPC1768 Boards" -> "Sudo rights". I'll just followed up the 3 mentioned steps, and it was working fine for me.

Configuration_adv.txt Configuration.txt

[parsko41]

Hi XylenC4,

Thanks for the configs. Mine are nearly identical regarding this subject. There wasn't anything notably different. I am wondering if my user permissions are the issue. I created an Operator account. This is how I use my OctoPi, not via the "pi" user account. I did try to add this username to the areas in the Wiki, but I'm not sure I did it right. I'm going to make another attempt. I know I'm close. I still have the same issue. Will report back if it is indeed the user account that is making this fail.

[parsko41]

I should also note that I do NOT have an LCD. As such, I also do not have an SD card on my LCD (cause I have no LCD). I use my printer strictly from the web interface.

I added myself to sudo, but I still can't see my usb mounts. Not sure if the SKR is not passing them through to the Pi or if the Pi is not able to see them. Hmmm.....

[XylenC4]

I have 2 printers, one with an SKR 1.3 without an LCD and one with an SKR 1.4 with an LCD (the SDCard on the LCD is not used). Both running OctoPrint on an RPI 3B in the latest image version.

I'm getting now the same issue as you described on my SKR1.3 which was working fine until I updated OctoPi. The last time I successfully used this plugin was 28.10.2020.

Applying the Wiki's recommendation worked for me, flashing firmware is now possible again.

1. Run sudo nano /etc/sudoers.d/020_firmware_updater to create a new file
2. Paste this line into the new file: pi ALL=NOPASSWD: /bin/umount
3. Save and close the file
4. sudo reboot

Make sure to reboot after such kind of modifications using "sudo reboot" in your terminal (or power cycle :] )

-> keep your system up to date with "sudo apt update -y && sudo apt upgrade -y"

Attached you can find my other config Configuration_adv.txt Configuration.txt

[parsko41]

Hi Xylen,

I still have not yet resolved this. I have posted the same issue with the SKR1.4 Github repository too. I am not sure if I can do that.

I did try what you asked, and updated/upgraded, still no luck. Thanks for your suggestions. I am not a Linux guru, and as such I don't quite know where to go on that path. Still researching. I am able to pull the SD card and update manually, which is okay, but a bit clunky, but working.

I will post on my progress.

Would it be possible for you to post your Firmware Updater settings on OctoPi? I am not sure if I have them set correctly. Please and thank you!

[parsko41]

[UPDATE] Okay, I've made some sort of progress. This is definately a mounting issue. After some searching how to mount stuff, I happened accross a command: sudo blkid /dev/sdv2 | awk -F'"' '{print $2}'

If I release my SD card via the "Files" sidebar options, then run the command above, then df -h, USB0 is mounted to /dev/sda1. I am then able to go into the firmware updater interface, select my firmware, press the button. NOW, the new result is: "Waiting for SD card to mount on host". So, that is something new and different. It won't allow me to mount and unmount from the Raspberry Pi.

Also, when I do this, I can no longer see the SD card in the File sidebar. It only asks to "Initialize SD card". Obviously, it's no longer mounted. I want to add that I can NOT add files to the SD card, even when mounted and visible in the Files sidebar. It won't upload, despite being able to choose a file and hitting okay to upload, just sits there spinning trying to refresh the file list (it's not a large file).

Thoughts?

[XylenC4]

Have you tried to use your computer to upload a firmware onto the SDCard via USB (not the SDCard directly)? You should see a new drive if connecting directly to your computer. To reset the controller you have to remove the red jumper briefly.

Have you tried to re-flash your RPI, update, just Setting Up Octo Pi. installing this plugin and follow up the wiki?

[parsko41]

Honestly, this add-on has had me spoiled by not having to drag my super long usb extension cable out every time I wanted to update the firmware (which was a lot a few months ago while first getting the printer going). I switched from a Mega to the SKR after Christmas, and I have just been moving the SD card back and forth now, which hasn't been as tedious as the usb extension cable.

In the back of my mind, you are exactly correct, I should have just reinstalled OctoPi, which I will. I have not wanted to lose my history or timelapses though, and been lazy in backing them up. The GPIO Shutdown add-on isn't working either... and I'm thinking of switching to Klipper... I'm losing steps on longer prints that I think is my drives overheating. I'm sure you're right that a fresh start is what I need, but I've got so many things! :) Thanks for the advice and support. Once I get this sorted, or make some progress I'll report back.

[XylenC4]

My intention on the first question was to make shure your SKR mounts the SDCard as USB-Drive correctly, just once to test and check if your bootloader is working well.

You don't have a second SDCard just to test if a new octopi is working? It does not mean it will :) Do not delete your current SDCard directly, I did this fault a coupe of times xD

[parsko41]

I have tried hooking the SKR to my computer via USB cable directly, and it is not mounting in Windows. I tried resetting the SKR via both the red jumper and the reset button, and it's not showing up. This was a bit of a surprise, actually.

This is progress. Seems like I configured something on the SKR wrong?

I definately have another SD card. My brain has shut down at that point last night from doing it. I'll go ahead and start fresh there, but this not mounting on Windows should be a thing.

On another note, tangential to this topic completely. If I power the SKR from the USB port, is that also powering the 5V rail for the servo/BLtouch, or does that come from the primary (higher voltage) power supply? I would like to keep it that way, as it's always "on" for the Pi once I connect to it. Now, it has to be toggled via my power supply, which also has it's advantages (and probably how I will leave it, prevents from having to press a reset button on the SKR).

Thanks for keeping with me!

[XylenC4]

I've just compiled MARLIN with your configuration, I'm able to connect and upload the firmware from the RPI using the FirmwareUpdater plugin.

Is there a reason for you to use the development branch? I'll just normally take the stable one as long as there is no other reason. You're also using #define SD_IGNORE_AT_STARTUP and #define MARLIN_DEV_MODE which I never used before.

The first step is to get your SKR mounted to your Computer as an External Drive, otherwise the FirmwareUpdater will either not be able to access your External Drive! -> Are you using the SDCard delivered with the SKR (~128MB) formatted in FAT

You should only use the USB connection for power on the first try to connect without anything connected. When the power is supplied over 5V the whole rail will come from your RPI/Computer which can blew up your 5V rail when it is not protected.

[parsko41]

I had an issue with the main branch, if I recall, not working. I'm still figuring out stable vs main, honestly. For some reason, Github has been tough for me to completely figure out despite being a mechanical engineer for 20 years and working with docoument management programs the whole time.

Dev mode enables "all the commands", from what I gather. This is a custom build, and I just assume to allow myself full access to everything. I'm not selling anything, and don't want access restricted. I do a lot of reading before I make large changes, and generally know my way around Marlin at this point, which is why this issue is baffling to me.

Thanks for the USB advice. I had assumed that as well, it's nice to get get outside confirmation. I have not looked THAT close to the schematic, but I did spend some time looking into it there, and left unconfirmed, although my intuition said it would be the case.

I have tried another SD card with the same results. BUT, I am still using the original SD, cause why not. The PI SD card needs to be big for timelapses. But the SKR doesn't need to be, as gcode files are small, if I ever used it for storing SD files. It's otherwise probably not that great of an SD card, I'm guessing. I have a quality one I can try when I start fresh with the new OctoPi refresh.

Why it won't mount via USB cable is certainly the first place to start. The #defind SD_IGNORE_AT_STARTUP was something I read that may be causing this issue. I'll toggle that first and give it a go. I'll play with this stuff tonight. My shift-of-death is also frustrating me. This SKR is not just a plug-n-play for me like the Mega was for some reason.

[LucienWells]

Just to add to this, I have exactly the same issue.

I have tried updating USBmount to 0.24 are suggested here.

It would seem the fundamental issue is that Marlin is not releasing the SD card. If I reboot the system and try the firmware updater plugin, I get a "The path is not writeable" error.

If I issue an M22 command via the terminal to have Marlin release the SD card, then the error goes away and the drive is accessible in /media/usb.

I might try the devmon suggestion here, but I would prefer to work out why the normal approach is broken.

Alternatively, some have suggested changing #define SDCARD_CONNECTION to LCD instead of ONBOARD. I have it set to ONBOARD at the moment, but unlike the person that suggested this, I am running a BTT TFT35.

[benlye]

Alternatively, some have suggested changing #define SDCARD_CONNECTION to LCD instead of ONBOARD. I have it set to ONBOARD at the moment, but unlike the person that suggested this, I am running a BTT TFT35.

I can't find it now, but I'm sure that someone at some point said that using the BTT LCD controller in touch mode causes this issue because it acts as a host, blocking the connection to the SD card from the Pi. I believe the only option was to not use the LCD in touch/host mode.

[LucienWells]

Alternatively, some have suggested changing #define SDCARD_CONNECTION to LCD instead of ONBOARD. I have it set to ONBOARD at the moment, but unlike the person that suggested this, I am running a BTT TFT35.

I can't find it now, but I'm sure that someone at some point said that using the BTT LCD controller in touch mode causes this issue because it acts as a host, blocking the connection to the SD card from the Pi. I believe the only option was to not use the LCD in touch/host mode.

I am not sure that is the issue after removing it from the equation.

I tried turning off the printer, physically disconnecting the TFT35, and then rebooting the Pi/OctoPrint and I still get the same The path is not writeable error message.

If I then issue the M22 command in the terminal, the plug-in then reports The path is valid.

Edit: I think this is the reference you might have been remembering.

[parsko41]

Well hey hey!!! Success.

I flashed a new Octoprint. Seems my old SD card was near full. Wonder if that had something to do with it? Either way, I went through the normal install, and it flashed, without a USB cable.

I made sure to upgrade to Python 3 as one of the first things I did. They are still using 2, I thought 3 was default, as I downloaded a fresh release. I followed your instructions, but, for some reason, I also added the sudo chmod 0777 /media/usb0, because I was having troubles seeing /media/usb0 from the "test" button on the web gui. I also followed this sequence.. https://community.octoprint.org/t/firmwareupdater-and-skr-1-3-lpc1768/15894/5 I really have no clue how any of that could lead to success. But, clues. I have a itchy feeling like the chmod may be needed?

Thanks to those that have helped.

Lucien, good luck. The solution may be as simple as the old IT one of a fresh start? Maybe ben can advise if Python 3 makes a difference?

[LucienWells]

I have also successfully managed to flash with the plugin now too, although I am not absolutely certain what sequence of events led to this as I do not have time to revert to a clean install and re-test.

Oddly, despite flashing being successful, the 'Test' button in the plugin was still failing with The path is not writeable. Octoprint's log says the following about that:

2021-01-15 11:55:56,542 - octoprint.server.api - ERROR - Error while testing if /media/usb0 is really writable
Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/server/api/__init__.py", line 516, in _test_path
    with io.open(test_path, "wb") as f:
PermissionError: [Errno 13] Permission denied: '/media/usb0/.testballoon.txt'

If like @parskofamily I do a sudo chmod 0777 /media/usb0, then the test button works.

Things I have done so far since having the initial problem up to the point of being able to flash successfully:

1. followed the configuration instructions
2. done the usual apt-get update and apt-get upgrade
3. updated USBmount to 0.24
4. updated the BTT TFT35's firmware with the following flag in the config.ini to ensure the TFT35 isn't trying to access the SD card of the SKR1.4 Turbo:

   #### Onboard / Printer SD Card Support
   # On Marlin firmware, the TFT will auto-detect Onboard SD Card.
   # Auto-detect is not available for other firmwares like Smoothieware.
   #   Options: [enable: 1, disable: 0, auto-detect: 2]
   onboard_sd_support:0

5. updated to Python 3
6. done the aforementioned sudo chmod 0777 /media/usb0

[benlye]

I would be careful modifying the permissions of the /media/usb0 mount point. The path test should succeed when the volume is mounted without needing to modify the permissions.

When you change the permissions you are enabling the test to succeed when the volume is not mounted, which is not really helpful.

Step 2 of the usbmount configuration has you configure the system so that the user pi has full control of the device when it is mounted: https://github.com/OctoPrint/OctoPrint-FirmwareUpdater#usbmount-installation

This should be all that is necessary.

On my system - no USB device mounted:

pi@octopi:/media $ ls -al
total 40
drwxr-xr-x 10 root root 4096 Dec  4 16:03 .
drwxr-xr-x 21 root root 4096 Feb 13  2020 ..
lrwxrwxrwx  1 root root    4 Dec  4 16:03 usb -> usb0
drwxr-xr-x  2 root root 4096 Dec  4 16:03 usb0

/media/usb0 is owned by root, no write access for anyone else but it doesn't matter.

Plug in a USB drive, with usbmount configured as per the instructions:

pi@octopi:/media $ ls -al
total 52
drwxr-xr-x 10 root root  4096 Dec  4 16:03 .
drwxr-xr-x 21 root root  4096 Feb 13  2020 ..
lrwxrwxrwx  1 root root     4 Dec  4 16:03 usb -> usb0
drwxr-xr-x  3 pi   pi   16384 Jan  1  1970 usb0

The user pi is automatically configured as the owner of usb0 so has full read/write permissions and the path test passes.

[benlye]

More explanation...

The point is that when usbmount has been set up correctly, you should not have to modify the permissions on /media/usb0. The usbmount/automount process automatically changes the permissions.

If you change the permissions on /media/usb0 without the board mounted you are effectively changing the permissions on an empty folder. The test will then pass without the board mounted, because the plugin can now write to the empty folder on your Pi. But this does not prove that the plugin can write to your printer's SD card, so it's pointless and gives you a false sense that things are working.

The default permissions prevent writing to /media/usb0 when the board is not mounted specifically so that the test will fail.

Bottom line, if you change the permissions things may look OK, but they are likely broken. Worst case, the firmware update appears to work, but it really hasn't, because instead of writing the new firmware to your printer's SD card, the plugin has just written it to a folder on your Pi.

So, if you have changed the permissions on /media/usb0, are you really sure that your firmware is updating (can you independently verify the update has been installed on the printer), or are you assuming it has because the plugin told you it succeeded and the printer restarted?

[parsko41]

Ben, you're right. I just made a change to my firmware, Z steps/sec from 640 to 320. Says it flashed successfully. I don't see the change showing up.

[benlye]

So you're back at square one, you need to get your firmware sorted so that the board presents the SD card so it can be mounted via USB.

This isn't a plugin problem, or probably even a Pi problem.

If you're more comfortable with Windows, just plug the board into your Windows PC. If it mounts as a USB drive move on to getting that to work on the Pi. If it doesn't, you need to figure out why.

Like I've said before, you need to find whatever magic combination of Marlin FW options configures the board to expose the SD card via USB. I don't have the board so can't help with that.

[LucienWells]

@benlye Thank you for the explanation. I changed the permissions to 755, which I think are default (?). As a result, the test button now no longer works.

Notwithstanding, I decided to test flashing (proper) again. This time the update would fail and the printer's serial port would disappear until a reboot of the printer:

2021-01-16 10:12:16,866 - octoprint.plugins.firmwareupdater - INFO - Firmware update started
2021-01-16 10:12:16,867 - octoprint.plugins.firmwareupdater - INFO - Disconnecting from printer
2021-01-16 10:12:16,920 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Offline"
2021-01-16 10:12:16,930 - octoprint.plugins.action_command_notification - INFO - Notifications cleared
2021-01-16 10:12:16,930 - octoprint.plugins.firmwareupdater - INFO - Synchronizing cached writes to SD card
2021-01-16 10:12:17,975 - octoprint.plugins.firmwareupdater - INFO - SD card not mounted, skipping unmount
2021-01-16 10:12:17,975 - octoprint.plugins.firmwareupdater - INFO - Pre-flash reset: attempting to reset the board
2021-01-16 10:12:17,975 - octoprint.plugins.firmwareupdater - INFO - Resetting LPC1768 at '/dev/ttyACM0'
2021-01-16 10:12:18,030 - octoprint.plugins.firmwareupdater - INFO - Waiting for LPC1768 at '/dev/ttyACM0' to reset
2021-01-16 10:12:18,464 - octoprint.plugins.firmwareupdater - INFO - LPC1768 at '/dev/ttyACM0' is resetting
2021-01-16 10:12:41,489 - octoprint.plugins.firmwareupdater - ERROR - Timeout waiting for board reset to complete
2021-01-16 10:12:41,490 - octoprint.plugins.firmwareupdater - ERROR - Board reset failed
2021-01-16 10:12:41,499 - octoprint.plugins.firmwareupdater - ERROR - Reset failed
2021-01-16 10:12:41,502 - octoprint.plugins.firmwareupdater - INFO - Reconnecting to printer: port=/dev/ttyACM0, baudrate=250000, profile={'axes': {'e': {'inverted': False, 'speed': 300}, 'x': {'inverted': False, 'speed': 6000}, 'y': {'inverted': False, 'speed': 6000}, 'z': {'inverted': True, 'speed': 200}}, 'color': 'default', 'extruder': {'count': 1, 'nozzleDiameter': 0.4, 'offsets': [(0.0, 0.0)], 'sharedNozzle': False}, 'heatedBed': True, 'heatedChamber': False, 'id': '_default', 'model': 'Creality Ender 5 Pro', 'name': 'Ender 5 Pro', 'volume': {'custom_box': False, 'depth': 220.0, 'formFactor': 'rectangular', 'height': 300.0, 'origin': 'lowerleft', 'width': 220.0}}
2021-01-16 10:12:41,578 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Opening serial connection"
2021-01-16 10:12:41,580 - octoprint.util.comm - INFO - Connecting to port /dev/ttyACM0, baudrate 250000
2021-01-16 10:12:41,593 - octoprint.util.comm - INFO - Changing monitoring state from "Opening serial connection" to "Error: Connection error, see Terminal tab"
2021-01-16 10:12:41,597 - octoprint.util.comm - INFO - Changing monitoring state from "Error: Connection error, see Terminal tab" to "Offline (Error: Connection error, see Terminal tab)"
2021-01-16 10:12:41,598 - octoprint.util.comm - ERROR - Unexpected error while connecting to serial port /dev/ttyACM0, baudrate 250000 from hook default: SerialException: '[Errno 2] could not open port /dev/ttyACM0: [Errno 2] No such file or directory: '/dev/ttyACM0'' @ comm.py:_open_serial:3670
Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.7/site-packages/serial/serialposix.py", line 322, in open
    self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
FileNotFoundError: [Errno 2] No such file or directory: '/dev/ttyACM0'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/util/comm.py", line 3670, in _open_serial
    settings().getFloat(["serial", "timeout", "connection"]),
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/util/comm.py", line 3644, in default
    serial_obj.open()
  File "/home/pi/oprint/lib/python3.7/site-packages/serial/serialposix.py", line 325, in open
    raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg))
serial.serialutil.SerialException: [Errno 2] could not open port /dev/ttyACM0: [Errno 2] No such file or directory: '/dev/ttyACM0'
2021-01-16 10:12:43,263 - octoprint.plugins.action_command_notification - INFO - Notifications cleared
2021-01-16 10:12:44,067 - octoprint.server.util.sockjs - INFO - Client connection closed: fe80::df:5db8:2a3a:5bdd
2021-01-16 10:13:18,523 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Detecting serial connection"
2021-01-16 10:13:18,562 - octoprint.util.comm - INFO - Serial detection: Performing autodetection with 0 port/baudrate candidates: 
2021-01-16 10:13:18,562 - octoprint.util.comm - INFO - Changing monitoring state from "Detecting serial connection" to "Error: No more candidates to test, and no working port/baudrate combination detected."
2021-01-16 10:13:18,564 - octoprint.util.comm - INFO - Changing monitoring state from "Error: No more candidates to test, and no working port/baudrate combination detected." to "Offline (Error: No more candidates to test, and no working port/baudrate combination detected.)"

I thought this was quite interesting: 2021-01-16 10:12:17,975 - octoprint.plugins.firmwareupdater - INFO - SD card not mounted, skipping unmount

So I went into the advance settings of the firmware updater and enabled and added M22 to the Pre-flash gcode field. It is probably unnecessary, but I also enabled the Pre-flash gcode delay and set it to 10 seconds.

Then I rebooted everything and tried to flash and it was successful:

2021-01-16 10:21:15,262 - octoprint.plugins.firmwareupdater - INFO - Got CONNECTED event
2021-01-16 10:21:15,263 - octoprint.plugins.firmwareupdater - INFO - Run postflash flag is not set
2021-01-16 10:22:03,324 - octoprint.plugins.firmwareupdater - INFO - Firmware update started
**2021-01-16 10:22:03,325 - octoprint.plugins.firmwareupdater - INFO - Sending pre-flash gcode commands: M22
2021-01-16 10:22:03,326 - octoprint.plugins.firmwareupdater - INFO - Pre-flash delay: 10s**
2021-01-16 10:22:13,337 - octoprint.plugins.firmwareupdater - INFO - Disconnecting from printer
2021-01-16 10:22:13,381 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Offline"
2021-01-16 10:22:13,386 - octoprint.plugins.firmwareupdater - INFO - Synchronizing cached writes to SD card
2021-01-16 10:22:13,401 - octoprint.plugins.action_command_notification - INFO - Notifications cleared
2021-01-16 10:22:14,445 - octoprint.plugins.firmwareupdater - INFO - Unmounting SD card: 'sudo umount /media/usb'
2021-01-16 10:22:14,595 - octoprint.plugins.firmwareupdater - INFO - Pre-flash reset: attempting to reset the board
2021-01-16 10:22:14,596 - octoprint.plugins.firmwareupdater - INFO - Resetting LPC1768 at '/dev/ttyACM0'
2021-01-16 10:22:14,679 - octoprint.plugins.firmwareupdater - INFO - Waiting for LPC1768 at '/dev/ttyACM0' to reset
2021-01-16 10:22:15,341 - octoprint.plugins.firmwareupdater - INFO - LPC1768 at '/dev/ttyACM0' is resetting
2021-01-16 10:22:18,567 - octoprint.plugins.firmwareupdater - INFO - LPC1768 at '/dev/ttyACM0' reset in 3.89 seconds
2021-01-16 10:22:18,568 - octoprint.plugins.firmwareupdater - INFO - Release the firmware lock on the SD Card by sending 'M22' to '/dev/ttyACM0'
2021-01-16 10:22:18,605 - octoprint.plugins.firmwareupdater - INFO - Waiting for SD card to be available at '/media/usb'
2021-01-16 10:22:38,631 - octoprint.plugins.firmwareupdater - INFO - Firmware update folder '/media/usb' available for writing after 20.0 seconds
2021-01-16 10:22:38,632 - octoprint.plugins.firmwareupdater - INFO - Copying firmware to update folder '/tmp/tmplc62szxv' -> '/media/usb/firmware.bin'
2021-01-16 10:22:39,285 - octoprint.plugins.firmwareupdater - INFO - Synchronizing cached writes to SD card
2021-01-16 10:22:40,352 - octoprint.plugins.firmwareupdater - INFO - Unmounting SD card: 'sudo umount /media/usb'
2021-01-16 10:22:40,447 - octoprint.plugins.firmwareupdater - INFO - Firmware update reset: attempting to reset the board
2021-01-16 10:22:40,448 - octoprint.plugins.firmwareupdater - INFO - Resetting LPC1768 at '/dev/ttyACM0'
2021-01-16 10:22:40,527 - octoprint.plugins.firmwareupdater - INFO - Waiting for LPC1768 at '/dev/ttyACM0' to reset
2021-01-16 10:22:41,184 - octoprint.plugins.firmwareupdater - INFO - LPC1768 at '/dev/ttyACM0' is resetting
2021-01-16 10:22:47,470 - octoprint.plugins.firmwareupdater - INFO - LPC1768 at '/dev/ttyACM0' reset in 6.94 seconds
2021-01-16 10:22:47,471 - octoprint.plugins.firmwareupdater - INFO - Flashing successful.
2021-01-16 10:22:47,478 - octoprint.plugins.firmwareupdater - INFO - No postflash gcode or postflash is disabled, setting run_postflash_gcode to false
2021-01-16 10:22:47,483 - octoprint.plugins.firmwareupdater - INFO - Reconnecting to printer: port=/dev/ttyACM0, baudrate=250000, profile={'axes': {'e': {'inverted': False, 'speed': 300}, 'x': {'inverted': False, 'speed': 6000}, 'y': {'inverted': False, 'speed': 6000}, 'z': {'inverted': True, 'speed': 200}}, 'color': 'default', 'extruder': {'count': 1, 'nozzleDiameter': 0.4, 'offsets': [(0.0, 0.0)], 'sharedNozzle': False}, 'heatedBed': True, 'heatedChamber': False, 'id': '_default', 'model': 'Creality Ender 5 Pro', 'name': 'Ender 5 Pro', 'volume': {'custom_box': False, 'depth': 220.0, 'formFactor': 'rectangular', 'height': 300.0, 'origin': 'lowerleft', 'width': 220.0}}

I changed the machine name in the firmware by adding "UPDATED" at the start so I could manually confirm the update with M115:

Send: M115
Recv: FIRMWARE_NAME:Marlin bugfix-2.0.x (Jan 16 2021 21:10:02) SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:UPDATED Ender-5 Pro SKR1.4 Turbo TMC2209 EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff

I then did it one more time for good measure, changing the machine name again by adding "ANOTHER TEST" at the start of the string:

Send: M115
Recv: FIRMWARE_NAME:Marlin bugfix-2.0.x (Jan 16 2021 21:35:06) SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:ANOTHER TEST Ender-5 Pro SKR1.4 Turbo TMC2209 EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff

So at least I am at the point where I can flash the board.

[benlye]

Glad you have it working, but I don't really understand why that would help.

The commands you added run before the pre-flash reset. After the reset the plugin also sends an M22. In your log you can see this followed by a 20s delay waiting for the SD card to mount.

So what's not clear to me is why sending M22 before the reset the board makes a difference after the reset.

2021-01-16 10:22:18,567 - octoprint.plugins.firmwareupdater - INFO - LPC1768 at '/dev/ttyACM0' reset in 3.89 seconds
2021-01-16 10:22:18,568 - octoprint.plugins.firmwareupdater - INFO - Release the firmware lock on the SD Card by sending 'M22' to '/dev/ttyACM0'
2021-01-16 10:22:18,605 - octoprint.plugins.firmwareupdater - INFO - Waiting for SD card to be available at '/media/usb'
2021-01-16 10:22:38,631 - octoprint.plugins.firmwareupdater - INFO - Firmware update folder '/media/usb' available for writing after 20.0 seconds
2021-01-16 10:22:38,632 - octoprint.plugins.firmwareupdater - INFO - Copying firmware to update folder '/tmp/tmplc62szxv' -> '/media/usb/firmware.bin'

[parsko41]

Hi again,

I'm sorry about all this Ben. This is wacky. Okay, fresh Saturday morning. I went through the 3 files you suggest modifying in your instructions, and all was exactly as you had it. I am working with a fresh install of Octopi, and the latest version of Marlin.

I was just able to update the firmware via your plugin, as one would expect it to work. I changed my machine name between each update, and it shows up in the Marlin EEPROM editor tab correctly. This is great!

A) Something different though. I am connected via the red jumper in USB mode. The SKR1.4 is connected and powered from the Raspberry Pi USB port. My 19V external power supply is off. I am able to update this way!

B) When I swap the Red Jumper to VDD mode, aka powered by my 19V external power supply, and the flash failed. I was not able to update the firmware this way.

C) Okay, I go to the file sidebar in the Octoprint Web GUI and release the SD Card. I am connected via my external 19V power supply, Red Jumper in VDD mode, and I am able to update the firmware! Success.

D) At no time throughout this am I able to see the USB when commanding "df -h" in a Putty session logged in as pi. If the SD card is initialized or not, it does not show up. I am not sure this is normal. UPDATE: I AM able to see it, but the card must be "Released" from Octoprint (via File sidebar).

E) I am not able to see the SKR1.4 when plugged in to my computer directly, and the red jumper set to USB. This is also a bit unexpected. This seems related to "D" above.

A, B, and C are within your realm, Ben. But, I know you don't have an SKR, and as such can't fully debug that side of things. I wanted to lay that out more logically above, and I just kinda went through the whole sequence. Seems it's an SRK thing, somehow? I don't really care, at this point, about being able to see the usb in Putty or on Windows, as I am able to remotely update firmware. I have the backup of just grabbing the SD card physically.

The ultimate magic, I think, was a fresh install, and all updated stuff. Also, my setting, the whole time, has been SDCARD_CONNECTION ONBOARD.

Note: I have "Reset before flashing" checked in the Firmware Updater configurations.

Note2: The test button does not work, either with the SD card Initialized from the File sidebard. The test button DOES work when the card is Not INitialized, aka Released.

Thanks. I think we all have solved this issue, but some mysteries still exist about the SKR behavior.

Now I need to start adding more Octoprint Add-on's (one by one this time) to get back to where I was on my old SD, which is full.

-Parsko

[github-actions[bot]]

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.