Add smoothie firmware mks sbase about octoprint-firmwareupdater

[benlye]

I think I've got a handle on the 'bug'. I don't understand why it happens, but I know how to work around it.

It seems that if I use the Python serial interface, pySerial, to issue commands to the LPC - like sending 'M997' to reset it - it will occasionally cause the usb-storage driver to have a Kernel Oops. If I use system commands like echo M997 >> /dev/ttyACM0 I never get the Kernel Oops - I've flashed my board 250 times consecutively, twice, without a single failure. Using pySerial I'd reliably have a failure after somewhere between 1 and 25 flashes. I'll release an update soon that takes care of this.

[CHILLYSMOKES]

@DavidBates Thanks for the tips but in actuality I will be running Marlin 2.x. The main reason for my request is to only ever have the Rpi connected by USB to the printer. I don't wanna disconnect/reconnect USB blablabla everytime I want to tweek something in firmware. I want the Rpi to do everything.

http://marlinfw.org/docs/basics/install_arm.html

I need Octoprint to mount the on-board SD card, find the hidden directory, and replace firmware.bin .

[benlye]

OK, I have a test version ready to go.

You can install it by going to Settings -> Plugin Manager -> Get More, and pasting in this URL:
https://github.com/benlye/OctoPrint-FirmwareUpdater/archive/lpc1768.zip

There is a dependency on the host being able to mount the SD card to a known mount point, which I've solved using a utility called usbmount, which needs to be installed and configured - please see the instructions and notes here:
https://github.com/benlye/OctoPrint-FirmwareUpdater/tree/lpc1768#lpc-1768-installation

I will add some more tests and checks as there seems to be some cases where host access to the SD card goes away, but looks like it's still there. A board reset before the firmware update seems to make it pretty robust (but note that it takes a few seconds for the SD card to be mounted after a reset).

Let me know if you have a chance to try it out.

[benlye]

I've updated my lpc1768 branch to make the process more robust.

The updater now resets the board before trying to do write the firmware file, with some checks around the reset process and a loop to wait up to 60s for usbmount to remount the SD card. It's worked flawlessly for about a dozen flashes of my SKR v1.1 board, for both Smoothie and Marlin.

If you're interested, give it a go. Unless I hear bad things I plan to push it out as a beta feature in a new release later in the week.

[benlye]

Awesome :-)

The v1.1 board came with Smoothie, so I assumed that the v1.3 would too, but that log says it's running Marlin 2.0.x bugfix.

M997, the reset command the plugin uses, was only added to Marlin two months ago, so the build they're shipping must be older than that, and that's why it wouldn't reset until you updated it.

I'll update the doc to include that advisory.

Ben

[benlye]

I managed to get another crash, even with the new plugin version. You and I have the same firmware/kernel and there is a newer version available. I've just run sudo rpi-update and will see if that helps.

[Alissonverd]

This plugin is working fine. (flashing without problem 1 time per boot)
For many users this will not become a problem. And this problem does not effect drastically the system. (we don't need remove sdcard to replace the firmware manually)
I only saw this problem for being testing the board ports, and I setup diferents firmwares to test each port.
What do you think?
maybe adds one note, explaining to the user do not despair if it fail. =D

Thank you for spend time with this plugin!
In my printer I can't remove the SD card to flash firmware, so this plugin is extremely necessary.

Best regards

[benlye]

Fix for the Pi Kernel Oops is in v1.4.0, just released.

[benlye]

If I understand this correctly, the update is done by simply copying a file named firmware.bin to the root of the SD card and resetting the printer?
http://smoothieware.org/flashing-smoothie-firmware

Shouldn't be too hard to support, but is quite different to the AVR process, so will need some thinking about how to do it. Will need to add support for different board types.

[userosos]

@benlye yes, copy just. But you need remember for config.txt.

[CHILLYSMOKES]

Your plugin is AWESOME!!! I got it to work perfectly with your YouTube video using ATMEGA2560... but alas I am upgrading to RE-ARM, which uses a 32-bit LPC1768 ARM processor, same processor as MKS SBASE. I have the same request as userosos. Just need to mount the board's micro-SD card, not the LCD's SD card. PLEASE!!!!!

[DavidBates]

@CHILLYSMOKES I haven't tried this plugin yet but in octoprint if you simply remove your LCD SD card smoothieware will mount the internal SD Card. Or at least thats what happens on my machine.

[benlye]

While I would love to do this, I don't have an MKS SBASE board, and I'm not in a position to get one right now. If anyone has the time to code something and test it I'm happy to take the look at it.

[Alissonverd]

https://github.com/bigtreetech
SKR1.1 and 1.3 are amazing boards and a little cheaper.
@benlye if I send one SKR1.1 to you, you will able to add this support?

thank you

[benlye]

@Alissonverd at those prices I'm OK to buy one myself, but thanks for the offer :-)

From a firmware uploading point of view, is there any functional difference between the v1.1 and v1.3 boards or will either serve my purposes?

[Alissonverd]

@benlye they use the same CPU, but I dont if will work with same code.

The USB schematic are the same.. But SD schematic is a bit different (maybe other chip)
https://github.com/bigtreetech/BIGTREETECH-SKR-V1.1/blob/master/hardware/SKR-V1.1SchDoc.pdf
https://github.com/bigtreetech/BIGTREETECH-SKR-V1.3/blob/master/hardware/SKR-V1.3-SCH.pdf

[benlye]

I had a quick scan through the docs and the Marlin config. I'm hoping that they're similar enough to be coded the same way, and that will also work with the other MKS Sbase boards. It certainly seems like the LPC1768 interface should be the same across them all.

I've ordered a v1.1 board from Amazon and should have it tomorrow.

Are you interested in flashing Marlin or Smoothieware?

[Alissonverd]

I want flash Marlin (marlin don't need config.txt)
@userosos @CHILLYSMOKES maybe we can make a donation to help with the costs of the board that benlye bought. Agree?
@benlye, send you paypal email, I will make a $10 donation, it's not much, but I hope it helps.

[Alissonverd]

@benlye the skr v1.1 board maybe don't have servo pins. v1.3 have only one.
https://github.com/bigtreetech/BIGTREETECH-SKR-V1.1/blob/master/hardware/SKR%20V1.1%20PINOUT.pdf

[benlye]

Got my v1.1 board and I'm making progress...

There is a difference in the pins files in the way the SD cards are used:
v1.1 - Onboard SD is presented to the USB host and used for Marlin (link)
v1.3 - Onboard SD is presented to the USB host and the LCD SD is used by Marlin (link)

I tried making my v1.1 board use the SD card on my LCD12864 by changing the settings but it doesn't seem to work. I'm not sure if it's supposed to work with this board.

In any case, as long as USB_SD_ONBOARD is enabled in the configuration (which is the case for both boards) the OctoPrint host should see the on-board card and be able to write the firmware file to it.

BTW, I'm working with the Marlin bugfix-2.0.x branch.

Smoothieware (at least the install that comes on the board) also only sees the on-board SD card, and presents the on-board card to the host.

If you'd like to send me a donation for the cost of the boards, that would be very nice! The email address in my Github profile works with Paypal.

Progress:

• Get an LPC1768 board (Got an SKR v1.1)
• Figure out how to reset the board via serial to make it self-flash (Marlin uses M997, Smoothieware uses reset, both can be sent as serial commands.)
• Figure out how to have OctoPrint find and mount the USB storage device so we can write the new firmware file to it
• Put it all together as a new flash method in the plugin

[Alissonverd]

@benlye I send one donation to you!
@userosos @CHILLYSMOKES, if have conditions, could you help with a small donation too?

Benlye,
Thank you for your work on this project. This level of coding I am not able to do.

[benlye]

@Alissonverd - thank you!

[Alissonverd]

I ordered yesterday one SKR1.3 on aliexpress. From China to Brazil will need 20 days =(

[benlye]

No worries - that gives me a bit more time to fine tune things :-)

In the meantime, if anyone else wants to try out the LPC1768 branch, feel free...

[remy561]

Tested on my SKR 1.3, works like a charm when the mounting works. However, sometimes I end up with an empty /media/usb folder, most often after rebooting the printer and reconnecting with octoprint.

Additionally, I'd recommend adding or linking to the usbmount documentation in the firmware flasher settings. This would immediately show that extra steps are required for this flashing method.

[remy561]

In addition to my previous response, this methods seems to work great after a reboot of the pi. However, when I reset my printer and keep the pi running, the /media/usb folder stays empty.

Edit:
I had a successful mount only twice so far. Once after the installation of the usbmount, and once after moving my printer to a different location. Several pi and printer reboots also did not help. So I guess we need something that triggers the mount after Octoprint connects or a manual mount button in the firmware uploader tool.

[benlye]

Do you have OctoPrint connecting automatically? I've found that the mount didn't always work if OctoPrint was connected first, as it mounts the SD card to Marlin. I'll try some other methods or to see if there is a more reliable way to do it, but am open to all suggestions. I might look at an option to disconnect OctoPrint, reset the board (without allowing OctoPrint to reconnect) , then look for the mount.

[remy561]

I had the option enabled, but disabling it didn't change much. I guess the main issue is that after mounting, it never remounts after a printer disconnect/reconnect. So, a button to unmount/remount might be the best option.

[benlye]

Strange, on mine it remounts every time if I reset the board with OctoPrint disconnected. I'll be able to do more testing next week.

[benlye]

@remy561, here's an alternative way using an entry in /etc/fstab. Can you see if it works any better?

1. Disable usbmount (if it's installed and enabled) by editing /etc/usbmount/usbmount.conf' and changing ENABLED=1toENABLED=0`.

2. Find the partition UUID of your SD card using blkid. In this example /dev/sda1 is the device, and the partition UUID is 35f62553-01:

pi@ben-pi:~ $ sudo blkid
/dev/mmcblk0p1: LABEL="boot" UUID="16D2-035F" TYPE="vfat" PARTUUID="eb943cb3-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="d065e631-6b9d-48c0-a8fe-e663b42828e0" TYPE="ext4" PARTUUID="eb943cb3-02"
/dev/sda1: LABEL="SDCARD" UUID="FB22-E729" TYPE="vfat" PARTUUID="35f62553-01"
/dev/mmcblk0: PTUUID="eb943cb3" PTTYPE="dos"

3. Edit /etc/fstab and add this line at the end (changing the UUID and mount point to suit your setup):

PARTUUID=[YOUR PARTITION UUID]  [YOUR MOUNT POINT]      vfat    sync,noexec,nodev,noatime,nodiratime,user,auto,gid=pi,uid=pi,dmask=0022,fmask=0111        0       0

Mine looks like this:

PARTUUID=35f62553-01  /media/lpc      vfat    sync,noexec,nodev,noatime,nodiratime,user,auto,gid=pi,uid=pi,dmask=0022,fmask=0111        0       0

4. Mount the volume by running mount [YOUR MOUNT POINT], e.g. mount /mnt/lpc

The catch is that the device must be manually mounted before it can be used by the plugin (for now you'll need to do that manually). It will be mounted if it's there when the Pi boots, but if you power on (or reset) the board after the Pi is running it won't mount automatically. I think I can easily automate that in the plugin.

[Alissonverd]

My board has not arrived yet, but when arrive you will have my support for tests.

Thank you!!

[RuediB]

I do not know if it helps, here's how I did it.
https://github.com/RuediB/32bit_FWupdate_for_Octoprint
Cheers!

[benlye]

I've just published the new release, v1.3.0, with lpc1768 board support. I'll update the documentation over the next few days. It should be pretty self-explanatory in the meantime.

Thanks, @RuediB. I slightly tweaked my process to make the pre-flash reset optional, and I've added configurable pre-flash and post-flash system command lines. The idea being that users could use a script similar to yours to mount the SD card before flashing.

Another option is to disable the pre-flash reset and use this command to have the udev daemon trigger usbmount to re-mount the board:
sudo umount /media/usb0; sudo udevadm trigger --action=add --subsystem-match=block

@Alissonverd, let me know if you have any issues once you get your board.

[thisiskeithb]

I'm not sure if this is an isolated case or a common issue with the BigTreeTech SKR 1.3, but I just finished migrating my OctoPi install (1.3.11rc3 running on OctoPi 0.15.0 / Raspbian 9 Stretch) from an AVR/MKS GEN-L board to an LPC1768/SKR 1.3 and ran into a slight hiccup.

I followed the installation instructions to install usbmount and everything appeared to install fine but the /media/usb directory could not be mounted despite several reboots of the SKR board & the pi.

I SSH'd into the PI and dug around and discovered the SKR's onboard SD card is mounted under /media/pi/disk instead. Once I changed the path in the plugin, everything worked like a charm edit: I have to reboot both the pi & SKR board after each flash or the plugin times out.

[RuediB]

Octoprint : 1.3.10
Octopi : 0.16.0
RPi : 3B+
BigTreeTech SKR 1.3
Works like expected.
@thisiskeithb Is there a 2nd sd card in your setup (TFT-Screen) that caused this problem, maybe?

[thisiskeithb]

@RuediB no other SD card present.

After a few more attempts at flashing the firmware today through this plugin, I found it's too finicky to reliably flash on the SKR 1.3. It will work once and then I have to reboot both the pi & the SKR board before it'll let me flash again.

[benlye]

That's weird. You should never have to reboot the Pi and the board gets rebooted automatically as part of the process.

Presumably the mount is going stale and the reboot of the Pi fixes it. There are other ways you could solve that with a pre-flash command.

Can you attach the OctoPrint logs from a failed attempt after a successful flash?

[benlye]

@thisiskeithb, having reread your initial problem about the mount point being different, it sounds like something other than usbmount is mounting the SD card, as AFAIK that will always mount to /media/usb.

Do you have a GUI desktop on your Pi? Sometimes they will automount USB devices, and that's not a scenario I tested.

[thisiskeithb]

@benlye: No GUI desktop installed. Since I’m running an OctoPrint RC, I’ll wait until the next final version to test this further.

[benlye]

OK. Let me know, as I'm sure we can figure it out.

[jeroen85]

Followed your instructions in Readme.md. Got it working now on SKR 1.3 with Marlin, very nice!
One small error in the readme.md

It is written to alter the FS_MOUNTOPTIONS as follows:
FS_MOUNTOPTIONS="-fstype=vfat,gid=pi,uid=pi,dmask=0022,fmask=0111

There is a " missing in the end, it should be
FS_MOUNTOPTIONS="-fstype=vfat,gid=pi,uid=pi,dmask=0022,fmask=0111"

Thanks for this very nice plugin!!

[benlye]

Followed your instructions in Readme.md. Got it working now on SKR 1.3 with Marlin, very nice!
One small error in the readme.md

Instructions fixed - thanks!

[Alissonverd]

@benlye All working fine!

With a factory firmware installed, we have "board reset fail"

2019-05-06 15:13:22,539 - octoprint.server.preemptive_cache - INFO - ... done in 17.73s
2019-05-06 15:15:32,795 - octoprint.plugins.firmwareupdater - INFO - Firmware update started
2019-05-06 15:15:32,812 - octoprint.plugins.firmwareupdater - INFO - Pre-flash reset: attempting to reset the board
2019-05-06 15:15:32,815 - octoprint.plugins.firmwareupdater - INFO - Resetting LPC1768 at '/dev/ttyACM0'
2019-05-06 15:15:32,827 - octoprint.plugins.firmwareupdater - INFO - Waiting for LPC1768 at '/dev/ttyACM0' to reset
2019-05-06 15:15:42,942 - octoprint.plugins.firmwareupdater - ERROR - Timeout waiting for board reset to init
2019-05-06 15:15:42,944 - octoprint.plugins.firmwareupdater - ERROR - Board reset failed
2019-05-06 15:15:42,949 - octoprint.plugins.firmwareupdater - ERROR - Reset failed
2019-05-06 15:15:58,873 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Opening serial port"
2019-05-06 15:15:58,876 - octoprint.util.comm - INFO - Changing monitoring state from "Opening serial port" to "Connecting"
2019-05-06 15:15:58,883 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2019-05-06 15:15:58,894 - octoprint.util.comm - INFO - Changing monitoring state from "Connecting" to "Operational"
2019-05-06 15:15:58,903 - octoprint.plugins.firmwareupdater - INFO - Got CONNECTED event
2019-05-06 15:15:58,905 - octoprint.plugins.firmwareupdater - INFO - Run postflash flag is not set
2019-05-06 15:15:58,908 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2019-05-06 15:15:58,926 - octoprint.util.comm - INFO - Printer reports firmware name "Marlin bugfix-2.0.x (Github)"
2019-05-06 15:15:58,929 - octoprint.util.comm - INFO - Firmware states that it supports temperature autoreporting
2019-05-06 15:16:00,047 - octoprint.plugins.tracking - INFO - Sent tracking event printer_connected, payload: {u'printer_baudrate': 115200, u'printer_port': u'/dev/ttyACM0', 'firmware_name': 'Marlin bugfix-2.0.x (Github)'}
2019-05-06 15:16:03,002 - octoprint.util.comm - INFO - Firmware states that it supports temperature autoreporting
2019-05-06 15:16:13,048 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Offline"
2019-05-06 15:16:13,163 - tornado.access - WARNING - 409 POST /api/printer/command
2019-05-06 15:16:13,178 - tornado.access - WARNING - 409 POST /api/printer/command
2019-05-06 15:16:50,274 - octoprint.plugins.firmwareupdater - INFO - Firmware update started
2019-05-06 15:16:50,294 - octoprint.plugins.firmwareupdater - INFO - Pre-flash reset: attempting to reset the board
2019-05-06 15:16:50,295 - octoprint.plugins.firmwareupdater - INFO - Resetting LPC1768 at '/dev/ttyACM0'
2019-05-06 15:16:50,307 - octoprint.plugins.firmwareupdater - INFO - Waiting for LPC1768 at '/dev/ttyACM0' to reset
2019-05-06 15:17:00,423 - octoprint.plugins.firmwareupdater - ERROR - Timeout waiting for board reset to init
2019-05-06 15:17:00,425 - octoprint.plugins.firmwareupdater - ERROR - Board reset failed
2019-05-06 15:17:00,430 - octoprint.plugins.firmwareupdater - ERROR - Reset failed

So, I did a first install of the firmware manually. After that the plugin started to work very well!

Thanks for this plugin!!

[thisiskeithb]

There is a " missing in the end, it should be
FS_MOUNTOPTIONS="-fstype=vfat,gid=pi,uid=pi,dmask=0022,fmask=0111"

This seems to have been the issue as I can now flash without any errors now. FYI: The instructions still haven't been updated to show the fix above.

[benlye]

There is a " missing in the end, it should be
FS_MOUNTOPTIONS="-fstype=vfat,gid=pi,uid=pi,dmask=0022,fmask=0111"

This seems to have been the issue as I can now flash without any errors now. FYI: The instructions still haven't been updated to show the fix above.

I updated the doc in the main repo (this one) two days ago. I guess you were still looking at the slightly older lpc1768 development branch in my repo? To avoid any confusion I've removed the dev branches.

Anyway, glad it's working for you now.

If everyone is happy I'll go ahead and close this issue.

[Alissonverd]

@benlye
We have a bug in the plugin, or maybe a bug in my installation.
When flash the firmware more then one time, without restart os system, the plugin generates an error after the "writing memory" or when "Resetting the board..." and make "board reset failed".

After this bug, I'm not able to reconnect board, the serial port disappear.. So, I need restart Pi hardware to be able to connect on board and flash again.
This bug make the button "reboot system" of octoprint unavailable to use.

My terminal tab after bug:

Connection closed, closing down monitor
Changing monitoring state from "Operational" to "Offline"
Connecting to: /dev/ttyACM0
Changing monitoring state from "Offline" to "Error: Connection error, see Terminal tab"
Unexpected error while connecting to serial port: /dev/ttyACM0 SerialException: '[Errno 2] could not open port /dev/ttyACM0: [Errno 2] No such file or directory: '/dev/ttyACM0'' @ comm.py:_openSerial:2478 (hook default)

Octoprint log: On this log, the bug appear after many flashs (+/- line 330)
octoprint.log

[benlye]

@Alissonverd It would be interesting if you could upload your /var/log/messages for the time of the failed flash attempt.

While testing this I just encountered the same issue and it looks like a kernel crash related to the usb-storage driver, which takes the Pi down (which is why the reset command also fails).

This is what I see in /var/log/messages just after the USB device disconnects:

May  9 10:00:35 ben-pi kernel: [  858.330326] CPU: 3 PID: 1857 Comm: usb-storage Tainted: G         C      4.14.98-v7+ #1200
May  9 10:00:35 ben-pi kernel: [  858.334879] Hardware name: BCM2835
May  9 10:00:35 ben-pi kernel: [  858.337186] task: ae570000 task.stack: ae43e000
May  9 10:00:35 ben-pi kernel: [  858.339549] PC is at prefetch_freepointer+0x20/0x2c
May  9 10:00:35 ben-pi kernel: [  858.341919] LR is at __kmalloc+0xfc/0x278
May  9 10:00:35 ben-pi kernel: [  858.344243] pc : [<80273950>]    lr : [<80277e5c>]    psr: 20000013
May  9 10:00:35 ben-pi kernel: [  858.346647] sp : ae43fbe8  ip : ae43fbf8  fp : ae43fbf4
May  9 10:00:35 ben-pi kernel: [  858.349081] r10: b9c01d80  r9 : 805b86fc  r8 : 014000c0
May  9 10:00:35 ben-pi kernel: [  858.351501] r7 : 0000007c  r6 : 00003b72  r5 : b9c01d80  r4 : b97e5580
May  9 10:00:35 ben-pi kernel: [  858.353975] r3 : 00000000  r2 : a0000013  r1 : 00000001  r0 : b9c01d80
May  9 10:00:35 ben-pi kernel: [  858.356426] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
May  9 10:00:35 ben-pi kernel: [  858.358964] Control: 10c5383d  Table: 391dc06a  DAC: 00000055
May  9 10:00:35 ben-pi kernel: [  858.514030] [<80273950>] (prefetch_freepointer) from [<80277e5c>] (__kmalloc+0xfc/0x278)
May  9 10:00:35 ben-pi kernel: [  858.517536] [<80277e5c>] (__kmalloc) from [<805b86fc>] (usb_alloc_urb+0x20/0x4c)
May  9 10:00:35 ben-pi kernel: [  858.521042] [<805b86fc>] (usb_alloc_urb) from [<7f2c8d98>] (acm_probe+0x53c/0xc68 [cdc_acm])
May  9 10:00:35 ben-pi kernel: [  858.524577] [<7f2c8d98>] (acm_probe [cdc_acm]) from [<805bdef4>] (usb_probe_interface+0x110/0x294)
May  9 10:00:35 ben-pi kernel: [  858.528117] [<805bdef4>] (usb_probe_interface) from [<80548208>] (driver_probe_device+0x244/0x300)
May  9 10:00:35 ben-pi kernel: [  858.531659] [<80548208>] (driver_probe_device) from [<80548470>] (__device_attach_driver+0xa4/0xbc)
May  9 10:00:35 ben-pi kernel: [  858.535202] [<80548470>] (__device_attach_driver) from [<805462f8>] (bus_for_each_drv+0x74/0xa8)
May  9 10:00:35 ben-pi kernel: [  858.538757] [<805462f8>] (bus_for_each_drv) from [<80547e7c>] (__device_attach+0xc0/0x120)
May  9 10:00:35 ben-pi kernel: [  858.542320] [<80547e7c>] (__device_attach) from [<80547ef8>] (device_attach+0x1c/0x20)
May  9 10:00:35 ben-pi kernel: [  858.545893] [<80547ef8>] (device_attach) from [<805bdbe4>] (rebind_marked_interfaces+0xb4/0xd0)
May  9 10:00:35 ben-pi kernel: [  858.549486] [<805bdbe4>] (rebind_marked_interfaces) from [<805bdc24>] (usb_unbind_and_rebind_marked_interfaces+0x24/0x28)
May  9 10:00:35 ben-pi kernel: [  858.553097] [<805bdc24>] (usb_unbind_and_rebind_marked_interfaces) from [<805b1058>] (usb_reset_device+0x1bc/0x224)
May  9 10:00:35 ben-pi kernel: [  858.556717] [<805b1058>] (usb_reset_device) from [<805f29dc>] (usb_stor_port_reset+0x64/0x74)
May  9 10:00:35 ben-pi kernel: [  858.560320] [<805f29dc>] (usb_stor_port_reset) from [<805f2c3c>] (usb_stor_invoke_transport+0x250/0x4bc)
May  9 10:00:35 ben-pi kernel: [  858.563935] [<805f2c3c>] (usb_stor_invoke_transport) from [<805f1720>] (usb_stor_transparent_scsi_command+0x18/0x1c)
May  9 10:00:35 ben-pi kernel: [  858.567556] [<805f1720>] (usb_stor_transparent_scsi_command) from [<805f3e24>] (usb_stor_control_thread+0x198/0x2a0)
May  9 10:00:35 ben-pi kernel: [  858.571176] [<805f3e24>] (usb_stor_control_thread) from [<8013de24>] (kthread+0x13c/0x16c)
May  9 10:00:35 ben-pi kernel: [  858.574776] [<8013de24>] (kthread) from [<801080ac>] (ret_from_fork+0x14/0x28)
May  9 10:00:35 ben-pi kernel: [  858.578489] ---[ end trace d7f91f048e66ab4a ]---

I've not seen this happen before and I must have flashed the board dozens of times. The only thing I can think of at this point is that almost all of my previous testing was done on an original Pi model B, but now I'm using a Pi 3 Model B, the same as you.

[benlye]

@Alissonverd please update to v1.3.1. I've added a step to unmount the SD card from the host before resetting the board. This seems to fix things for me - I had three crashes in about 20 flashes before I made the change, but none afterwards in another 20+ flashes.

It also has the advantage that the SD card no longer gets flagged as having a dirty filesystem.

[Alissonverd]

@benlye This is my /var/log/messages.
var_log_msgs.txt

Thank you for this update, I will do the same test that causes this bug.

Best regards

[Alissonverd]

Same error;
But now the "reboot system" don't send a error command, but do nothing.
I'm not able to connect via ssh;
Serial port disappears;

Logs: (v1.3.1)
var_log_msg_v1.3.1.txt
octoprint_v1.3.1.log

Edit: My Pi is from china ;) (maybe the problem?)
Sorry my poor english, this is not my native language. Thank you for patience with this.

[Alissonverd]

@benlye
I run the commands:

sudo rpi-update
sudo reboot
sudo apt-get update -y && sudo apt-get upgrade -y
sudo reboot

And same error appear after update kernel and packages.

[benlye]

You're doing better than me - after the rpi-update I now have about a 2-3 minute lag between clicking 'Update' in the browser and the back-end actually starting the update. It was instant before, and I have no idea what's gone wrong. I think I'll be re-flashing this Pi.

Update: Running sudo apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel restores the stable kernel and stuff works again.

I think we may have stumbled on some kind of kernel/hardware/driver bug which may only affect this platform - I didn't have this issue when testing on an old model B or a newer 3 B+. I'll spend some more time on this but I'm not sure I have the skill set to figure it out and fix it.

[thisiskeithb]

Thank you for fixing the consecutive flashing bug! I thought my Pi was going bad after lockups when dialing in Marlin on my SKR 1.3.

[benlye]

I'll close this issue now. You can always open a new one if there are any further problems.

[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.