-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add smoothie firmware mks sbase #18
Comments
If I understand this correctly, the update is done by simply copying a file named 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. |
@benlye yes, copy just. But you need remember for config.txt. |
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!!!!! |
@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. |
@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 . |
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. |
https://github.com/bigtreetech thank you |
@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? |
@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) |
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? |
I want flash Marlin (marlin don't need config.txt) |
@benlye the skr v1.1 board maybe don't have servo pins. v1.3 have only one. |
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: 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 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:
|
@benlye I send one donation to you! Benlye, |
@Alissonverd - thank you! |
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: 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: 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. |
I ordered yesterday one SKR1.3 on aliexpress. From China to Brazil will need 20 days =( |
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... |
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. |
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: |
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. |
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. |
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. |
@remy561, here's an alternative way using an entry in
Mine looks like this:
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. |
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. |
My board has not arrived yet, but when arrive you will have my support for tests. Thank you!! |
I do not know if it helps, here's how I did it. |
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 @Alissonverd, let me know if you have any issues once you get your board. |
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 I SSH'd into the PI and dug around and discovered the SKR's onboard SD card is mounted under |
Octoprint : 1.3.10 |
@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. |
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? |
@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. |
@benlye: No GUI desktop installed. Since I’m running an OctoPrint RC, I’ll wait until the next final version to test this further. |
OK. Let me know, as I'm sure we can figure it out. |
Followed your instructions in Readme.md. Got it working now on SKR 1.3 with Marlin, very nice! It is written to alter the FS_MOUNTOPTIONS as follows: There is a " missing in the end, it should be Thanks for this very nice plugin!! |
Instructions fixed - thanks! |
@benlye All working fine! With a factory firmware installed, we have "board reset fail"
So, I did a first install of the firmware manually. After that the plugin started to work very well! Thanks for this plugin!! |
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 |
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. |
@benlye 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. My terminal tab after bug:
Octoprint log: On this log, the bug appear after many flashs (+/- line 330) |
@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:
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. |
@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. |
@benlye This is my /var/log/messages. Thank you for this update, I will do the same test that causes this bug. Best regards |
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 |
Same error; Logs: (v1.3.1) Edit: My Pi is from china ;) (maybe the problem?) |
@benlye
And same error appear after update kernel and packages. |
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 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. |
This plugin is working fine. (flashing without problem 1 time per boot) Thank you for spend time with this plugin! Best regards |
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 |
Fix for the Pi Kernel Oops is in v1.4.0, just released. |
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. |
I'll close this issue now. You can always open a new one if there are any further problems. |
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. |
You can add mks sbase and other smoothie's bsases firmware. You need just add support mount sd card builtin an mks sbase and copy to the sd card firmware.bin and config.txt file. Add "Reset" nedd also, for reboot mks sbase for install the firmware.
The text was updated successfully, but these errors were encountered: