Klipper: Firmware restart does not work on SKR 1.3

[JoaoFelipe]

I'm installing Klipper on a SKR 1.3 and trying to configure sensorless homing with a TMC2209.

When I turn on the printer the first time, Klipper connects to the printer and works fine: I can send G28 X, for instance and it tries to home X.

However, as I'm configuring sensorless homing, I need to change the configuration of driver_ SGTHRS and reload the configuration file. However, when I try to send FIRMWARE_RESTART or RESTART to the printer, it disconnects but does not connects back.

Sometimes, it connects back when I turn off the printer and turn on again. Other times, I have to do sudo service klipper restart to be able to connect again.

Any suggestions?

klippy.log

PS: I'm using a printer.cfg that I used with this board a while back with TMC2208. I haven't used this board (nor Klipper) for months.
PPS: the heater bed is not working as well, but I'm trying to make the steppers work with sensorless homing before looking into it. The wires are probably the problem

[Coffee0297]

In the Settings tab, navigate to the “Behavior” sub-tab and select the “Cancel any ongoing prints but stay connected to the printer” option. Click “Save”.

[JoaoFelipe]

This option were already selected

[BlackStump]

have you updated the firmware on the skr?

[JoaoFelipe]

Yes. And I had to run make clean before make to compile the new version of the firmware.

[KevinOConnor]

The original batch of SKR v1.3 boards used the bootloader from: https://github.com/triffid/LPC17xx-DFU-Bootloader . All recent boards use a different bootloader (which also doesn't support flashing over usb).

I've seen similar reports of this issue on the newer batch of boards. It is not known if it is a problem with the bootloader, or the interaction with Klipper. I've not seen any reports of this type of issue with the original bootloader.

You should not have this issue with RESTART, so that's the simplest solution - don't use FIRMWARE_RESTART unless you need to clear an error from the micro-controller.

-Kevin

[JoaoFelipe]

I think my SKR 1.3 is from one of the first batches, but I'm not sure. Is there a way to check which bootloader do I have? Is it possible to replace it? Are there any drawbacks?

I'm in the middle of a print (with Marlin), so I can't test it now, but I'll try the RESTART command later. I think I already tried it, though, but I'm not sure if I only tried it after the home halting due to a bad configured driver_SGTHRS.

By the way, is it possible to define driver_SGTHRS values without reloading the printer? Such as using the M914 gcode? Also, how does _STALL_SENSITIVITY relate to driver_SGTHRS? In Marlin, I found the value 40 for my TMCs 2209. Should I use the same value in Klipper?

[vladbabii]

@JoaoFelipe - https://github.com/KevinOConnor/klipper/blob/master/docs/G-Codes.md look at the tmc-specific commands.

[gloomyandy]

So the bootloader story goes like this....

The original SKR V1.1 and V1.3 boards used the standard smoothieware bootloader. However that has code that checks one of the LPC176x pins to see if it should enter dfu mode (and allow control of the loader via USB/serial). This worked fine on the original smoothieboard as they had a jumper for this. However on the SKR boards the pin that was being tested was wired into the extruder stepper driver! So shortly after release there were reports of how having certain stepper driver modules installed would result in the board "failing to boot", not long after this, the problem was "fixed".

I have one of the early SKR V1.3 boards and was doing some work on the Marlin USB code. While trying to help several users with watchdog timeout issues that seemed to behave differently on their (more recent) SKR boards than it did on mine, I got a little suspicious and contacted one of the BTT developers to ask what they had actually done to the bootloader. It turns out that rather than simply remove the test on the pin for entering dfu mode, they commented out all of the code that can cause the bootloader to go into this mode (one of the other ways to get into dfu mode is to trigger a watch dog timer reset - this is how klipper does it). So long story short, newer versions of the SKR V1.3 board are not able to enter dfu mode and so can not be updated via the USB/serial port.

I suppose someone could fix the bootloader properly, but that would then require users to install that new version.

[KevinOConnor]

@gloomyandy - Thanks!

-Kevin

[mattthebaker]

@JoaoFelipe any chance you're using the 5V_USB jumper on your SKR? I've always had issues it in that configuration.

[JoaoFelipe]

@mattthebaker It is very unlikely. Marlin is working fine and if I'm not mistaken, it does not work with the 5V_USB jumper.

PS: I still haven't tried the suggestion to use the RESTART command instead. I'll try it by tomorrow.

[Arksine]

EDIT: Disregard this, apparently the old bootloader is indeed checking P2.12, I just got duped by the labeling. I'll see if I can get a version to build correctly that does not do this.

I looked into fixing the bootloader, however if you are using the smoothieware bootloader linked below it should not check the play pin (P2.12) to enter the dfu mode. That wasn't added until 2017 in triffid's develop branch. FWIW, it seems like the addition of armcc support in that branch broke the gcc build.

https://github.com/Smoothieware/Smoothieware/tree/edge/bootloader

[Arksine]

For those interested, you can find an updated bootloader here.

https://github.com/Arksine/LPC17xx-DFU-Bootloader/releases/tag/0.4.1

You can flash DFU-bootloader.hex using the serial programmer, or go the easy route and use betterBootloader.bin to flash via sdcard. If you choose to flash via sdcard it will also flash Klipper. You can then flash a fresh build of Klipper using "make flash", or flash Marlin using the sd card.

[Ph0rkoz]

Dude, you are my hero.

[vladT0]

Hi All !
Seems I met the same issue with SGEN_L board. Extruder is not working for me at all. I have flashed smothieware and motor turns after G1 E100 command. For the Klipper command G92 E0 and G1 E100 executed with OK status, but motor doesn't react at all. Tried TMC2209 and LV8729. Flashed modified boot loader, did not help. I had idea "enable_pin: P2.12" is the reason. Thanks in advance for any help and suggestions.
P.S. Tried to extrude with OctoPi control panel, but in this case
I have got "Unknown command:"T0"" See log.

Edit: Found reason why motor was not working. Just need to invert enable pin. Bootloader was not main reason. Closed. , but "Unknown command:"T0" is still there.

klippy.log
printer.txt

[mapfde]

@Arksine
I have an SKR 1.1 that does not work with an LV8729 in E0 - most likely because of this bootloader issue. Will your betterbootloader file work with the SKR 1.1 as well?

[mattthebaker]

Yes, it will work with SKR 1.1 as well.

[KevinOConnor]

Okay, I'm going to close this as it looks like the conversation has concluded. As far as we know, the Klipper code works as intended on the lpc176x chips.

-Kevin