Update SKR-boards using programmer, to avoid SD cards about kiauh HOT 12 CLOSED

Am I misunderstanding anything? You say awfull SD-card switcherino for one last time, but it's each time, klipper-repo updates or minor changes have been made. Right?

Oh okay! Now i get you. So you weren't aware of that there actually exists a working bootloader you can flash only once and then be able to flash the SKR over USB? Whoops my bad! I thought you were aware and suggested your idea now as an alternative way.

So yeah you almost linked the right bootloader already. Personally i can suggest this one here:
https://github.com/Arksine/LPC17xx-DFU-Bootloader/releases/tag/0.4.1

I flashed it to my own SKR1.4T and it worked flawless. I can now flash the SKR via USB.

I'm not complaining about that warning! ;) Important notice for SKR / smoothie board users!

I didn't take it as a complaint :)

from kiauh.

Hi, thank you for sharing the idea.

Are there any downsides to the bootloader method that makes the programmer method superior?
I flashed my SKR1.4T with it and i haven't encountered any downsides yet. It just works.

The main goal of both methods would be to avoid swapping SD-cards when updating the MCU firmware.
You say that, when using the programmer method, it would require the user to hook up the boards to a corresponding programmer. That means additional hardware is necessary, right?
In comparison, the bootloader method doesn't require new/additional hardware one might have to buy beforehand. You just take the already existing SD-card (yes i know you have to do the awfull SD-card switcherino for one last time).

So tbh i don't quite see the benefit of the new method over the old method. Also you say that it might needs a lot of testing. In comparison the bootloader is more like an already "established" method, and i haven't heard bad things about it yet. Just flash it and go.

Oh and regarding that warning: thats hardcoded 😛 hehe
So that won't get eliminated unless i remove it from the script 😄 it's a warning which gets displayed for everyone and everytime.

from kiauh.

Are there any downsides to the bootloader method that makes the programmer method superior?

There are serval reports, about issues with the sd card reader.. Due to broken pins or incorrect sd formatting, .. https://community.platformio.org/t/skr-1-4-bricked/12932/25
I want to avoid breaking my board over time and automate it.

Am I misunderstanding anything? You say awfull SD-card switcherino for one last time, but it's each time, klipper-repo updates or minor changes have been made. Right?

I wondering if it's possible to flash a bootloader, that enables flashing through USB-Serial. Read about in the smoothieboard documentation. That's what I'm aiming for. Using the existing USB-Serial connection to flash the MCU instead of SD-card swapping. See:

• https://www.klipper3d.org/Bootloaders.html#lpc176x-micro-controllers-smoothieboards
• https://github.com/ardiehl/BTT_SKR_13_14_14T_SD-DFU-Bootloader

I'm not complaining about that warning! ;) Important notice for SKR / smoothie board users!

from kiauh.

Great! Exactly what I was looking for! I'm using 3-wire-connection in my setup and I'm getting Failed to flash to /dev/ttyAMA0: Unable to find tty usb device, when flashing klipper using make flash **FLASH_DEVICE=/dev/ttyAMA0.

So why not integrate it? Maybe ask the user to manually flash the betterBootloader.bin one last time?

from kiauh.

So why not integrate it? Maybe ask the user to manually flash the betterBootloader.bin one last time?

Because that has to be done manually. Or am i getting you wrong now? What exactly do you mean with "integrating" now?
You need to download the betterBootloader.bin, copy it on the SD-Card and put the card back into the SKR.
After that bootloader was flashed, future flashing of the MCU can be done via USB. That process is not really something which can be "integrated" into KIAUH since well, you have to download the bootloader and put it on the SD-card by hand.

from kiauh.

Yes you're getting me wrong. I meant automating it for people that already got betterBootloader.bin flashed! ;) Not that physical process. Automating the "update process", to complie klipper, stop klipper, flash klipper.bin and start klipper again.

Similar, to what klipper is already offering for smoothieware / DFU:

from kiauh.

Since i have no idea on how to make the script automatically detect if an mcu firmware update is necessary after updating the local klipper repo with a git pull, i don't see a way for automating it.

There is no source (at least that i know of) where you can read from that the (or better YOUR) board needs to be flashed again. Most of the time you will only know, once you get the corresponding error message in the logfile or your webinterface. And there already were cases that not every boardtype needed a new flash, because the mcu code for only a specific kind of board or cpu model was updated.

from kiauh.

I dont know anything about this "hardware level" Stuff, but...
I use a program called betaflight to program and flash Flightcontrollers of RC Drones ( uuuh, he said DRONES -- I mean Quadrocopter :) ) that are likely similar to Printer Boards as far an STM32 CPU doing its thing on it.
The point is with every Release comes a new Firmware and maybe someone can reverse engineer the technic to display the version of the firmware. If, then there where a possibility to match some numbers for the script.

Merry Christmas to everyone.

from kiauh.

Since i have no idea on how to make the script automatically detect if an mcu firmware update is necessary after updating the local klipper repo with a git pull, i don't see a way for automating it.

Actually I don't think you have to. Flashing the MCU each time you the klipper repo doesn't hurt. Right? It's possible to ask the user whether he wants to flash.

I wouldn't dismiss that idea. Maybe I try to implement it myself, one day 😉

from kiauh.

Flashing the skr everytime hurts! Flashes „wear“ out on write cycles and have a maximum of them specified in the Specifikation. So do only flash the mcu if klipper tells you.

from kiauh.

Short update on this topic:
It is now possible to flash all listed board in the initial post via their sdcard once they got flashed before at least once:
https://github.com/KevinOConnor/klipper/blob/master/docs/SDCard_Updates.md
That process already got implemented in KIAUH too:
938b9d2

<< Closing >>

from kiauh.

Are there any downsides to the bootloader method that makes the programmer method superior?

There are serval reports, about issues with the sd card reader.. Due to broken pins or incorrect sd formatting, .. https://community.platformio.org/t/skr-1-4-bricked/12932/25 I want to avoid breaking my board over time and automate it.

Am I misunderstanding anything? You say awfull SD-card switcherino for one last time, but it's each time, klipper-repo updates or minor changes have been made. Right?

I wondering if it's possible to flash a bootloader, that enables flashing through USB-Serial. Read about in the smoothieboard documentation. That's what I'm aiming for. Using the existing USB-Serial connection to flash the MCU instead of SD-card swapping. See:

• https://www.klipper3d.org/Bootloaders.html#lpc176x-micro-controllers-smoothieboards
• https://github.com/ardiehl/BTT_SKR_13_14_14T_SD-DFU-Bootloader

I'm not complaining about that warning! ;) Important notice for SKR / smoothie board users!

lol I know where you are coming from! They break so easy don't they! But once they work they do, just important not to even break on it (probably vulnerable to static and all sorts) 🙂

from kiauh.