Closed vladbabii closed 5 years ago
@anm8tor - try the firmware I uploaded above, it should work
@vladbabii This image replaces both Klipper and Octopi on the Pi4?
That's klipper firmware for the board
I got a chance to compile Klipper on an Ubuntu 18.04 VM. However, I was unable to reproduce the problem. I compiled for stm32f103 (with an 8KiB bootloader) and the resulting binary came up fine on my "blue pill" test board.
Could you verify the problem is still present with the very latest Klipper version?
-Kevin
I have also lost the usb when updating firmware on this board. if put firmware.bin from a few weeks ago it finds the usb again but with the latest pull and compiled firmware.bin there is no serial in /dev firmware compiled on beaglebone black debian. [ 1.529782] usb 1-1: new full-speed USB device number 2 using musb-hdrc [ 1.661704] usb 1-1: device descriptor read/64, error -32 [ 1.905657] usb 1-1: device descriptor read/64, error -32 [ 2.153739] usb 1-1: new full-speed USB device number 3 using musb-hdrc [ 2.281741] usb 1-1: device descriptor read/64, error -32 [ 2.494512] [drm] Cannot find any crtc or sizes [ 2.529765] usb 1-1: device descriptor read/64, error -32 [ 2.645844] usb usb1-port1: attempt power cycle [ 3.089776] usb 1-1: new full-speed USB device number 4 using musb-hdrc [ 3.633748] usb 1-1: new full-speed USB device number 5 using musb-hdrc
with old firmware [ 1286.741568] usb 1-1: new full-speed USB device number 6 using musb-hdrc [ 1286.890843] usb 1-1: New USB device found, idVendor=2341, idProduct=abcd [ 1286.890863] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1286.890872] usb 1-1: Product: Klipper firmware [ 1286.890879] usb 1-1: Manufacturer: Klipper [ 1286.890887] usb 1-1: SerialNumber: 12345 [ 1286.956736] cdc_acm 1-1:1.0: ttyACM0: USB ACM device [ 1286.967049] usbcore: registered new interface driver cdc_acm [ 1286.967067] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
@vladbabii Forgive my ignorance, this is still very new to me. My understanding was that I need Octoprint/Octopi and Klipper installed together. Are you saying I can just install the Killer image?
@anm8tor https://octoprint.org/ Octoprint is a web interface for 3d printers and not the only web interface that can be used with klipper just the web interface of choice by the dev.
Octopi is a image for the rasberrypi sbc that has octoprint already installed.
Klipper is software/firmware for 3d printer they are not the same and not dependent on each other but can be used together .
have you read the install process? https://github.com/KevinOConnor/klipper/blob/master/docs/Installation.md
@blackstump Thanks for the response. I haven't read the entire thing, but the first line in the file is what I was referencing. I originally commented on this thread, because my Pi4 with the following Octopi image doesn't see my SKR mini at all, but sees other USB devices just fine.
https://storage.googleapis.com/octoprint/2019-06-24_2019-06-20-octopi-buster-lite-0.17.0.zip
@anm8tor You can run
dmesg -c
to clear all message logs from pi, then plugin the usb cable then run
dmesg
and you can get the logs from the pi of what the pi sees when the board gets plugged in. You can attach the log here or copy-paste it so we can see what error you get.
Also, try using the reset button on the board after flashing.
@anm8tor i will try later today the firmware image i sent you - i need to buy a new microsd card, the last one died on me and i only have 128gb ones that won't work with the skr.
Alas, I'm unable to reproduce this failure. If this is still an issue, please checkout a known good version of Klipper (git checkout <revision>
), compile it, load it on the board, obtain the klipper log, grab the out/ directory (tar cfz klipper-good.tar.gz out/
). Then checkout the latest version of Klipper (git checkout origin/master
), compile it on identical machine and compiler, load it on the board, grab the klipper log, grab the out/ directory (tar cfz klipper-bad.tar.gz out/
). Finally, attach all four files here along with the OS revision (cat /etc/os-release
) and compiler version (arm-none-eabi-gcc --version ; arm-none-eabi-ld --version
).
-Kevin
@anm8tor You can run
dmesg -c
to clear all message logs from pi, then plugin the usb cable then run
dmesg
and you can get the logs from the pi of what the pi sees when the board gets plugged in. You can attach the log here or copy-paste it so we can see what error you get.
Also, try using the reset button on the board after flashing.
@vladbabii - this produces nothing, as the Pi "sees" no changes once I plug the usb cable in. In reference to the firmware image, does that go straight onto my board, in place of the Marlin firmware, or on the Pi? If the latter, I'm not sure it will change the fact that plugging in the cable triggers no signal
@anm8tor I had the exact problem with skr mini 1.1 - it was working fine and as soon as I updated to latest version of klipper firmware I started getting the device descriptor read/64, error -32 error. After few tries that error went away but pi stopped seeing the usb connection at all. I did manage to get klipper connected with the same board using serial pins but was unstable. I gave up and got an skr1.3 which has been working great. IMHO this has something to do with the board and not Klipper.
I compiled on a spare beaglebone black with a clean install of debian and a clean install of klipper I compiled the skr-mini firmware and test on the board. I reverted back to commit 7efc53ff59111061908405dae889a38cc6e60dbb I complied the skr-mini firmware and test on the board. I used that sdcard with the clean install on the printer that has the beaglebone black replicape skr mini attached, I did not want to strip the printer just to hook up the skr mini on the spare beaglebone black. The klipper version will come up as dirty only because I had to use a modified klipper_pru_start.sh which I have included klipper-pru-start.zip klipper-good.tar.gz klipper-bad.tar.gz klippy_good.log klippy_bad.log os.txt
Just tested master on my SKR MINI E3:
[ 164.414664] usb 6-1: new full-speed USB device number 6 using ohci-platform
[ 164.606661] usb 6-1: device descriptor read/64, error -32
[ 164.906664] usb 6-1: device descriptor read/64, error -32
[ 165.202655] usb 6-1: new full-speed USB device number 7 using ohci-platform
[ 165.394656] usb 6-1: device descriptor read/64, error -32
[ 165.694660] usb 6-1: device descriptor read/64, error -32
[ 165.802707] usb usb6-port1: attempt power cycle
[ 166.306658] usb 6-1: new full-speed USB device number 8 using ohci-platform
[ 166.722655] usb 6-1: device not accepting address 8, error -32
[ 166.910659] usb 6-1: new full-speed USB device number 9 using ohci-platform
[ 167.326648] usb 6-1: device not accepting address 9, error -32
[ 167.326721] usb usb6-port1: unable to enumerate USB device
.config
#
# Automatically generated file; DO NOT EDIT.
# Klipper Firmware Configuration
#
CONFIG_LOW_LEVEL_OPTIONS=y
# CONFIG_MACH_AVR is not set
# CONFIG_MACH_ATSAM is not set
# CONFIG_MACH_ATSAMD is not set
# CONFIG_MACH_LPC176X is not set
CONFIG_MACH_STM32=y
# CONFIG_MACH_STM32F0 is not set
# CONFIG_MACH_PRU is not set
# CONFIG_MACH_LINUX is not set
# CONFIG_MACH_SIMU is not set
CONFIG_STEP_DELAY=2
CONFIG_BOARD_DIRECTORY="stm32"
CONFIG_MCU="stm32f103xb"
CONFIG_CLOCK_FREQ=72000000
CONFIG_USBSERIAL=y
CONFIG_SERIAL_PORT=1
CONFIG_FLASH_START=0x8007000
CONFIG_FLASH_SIZE=0x10000
CONFIG_RAM_START=0x20000000
CONFIG_RAM_SIZE=0x5000
CONFIG_STACK_SIZE=512
CONFIG_STM32_SELECT=y
CONFIG_MACH_STM32F103=y
# CONFIG_MACH_STM32F405 is not set
# CONFIG_MACH_STM32F407 is not set
# CONFIG_MACH_STM32F446 is not set
CONFIG_MACH_STM32F1=y
CONFIG_HAVE_STM32_USBFS=y
# CONFIG_HAVE_STM32_USBOTG is not set
# CONFIG_STM32_FLASH_START_2000 is not set
CONFIG_STM32_FLASH_START_7000=y
# CONFIG_STM32_FLASH_START_0000 is not set
CONFIG_STM32_CLOCK_REF_8M=y
# CONFIG_STM32_CLOCK_REF_INTERNAL is not set
CONFIG_CLOCK_REF_8M=y
#
# USB ids
#
CONFIG_USB_VENDOR_ID=0x2341
CONFIG_USB_DEVICE_ID=0xabcd
CONFIG_USB_SERIAL_NUMBER="12345"
# CONFIG_CUSTOM_STEP_DELAY is not set
CONFIG_INITIAL_PINS="!PC13"
CONFIG_HAVE_GPIO=y
CONFIG_HAVE_GPIO_ADC=y
CONFIG_HAVE_GPIO_SPI=y
CONFIG_HAVE_GPIO_I2C=y
# CONFIG_HAVE_GPIO_HARD_PWM is not set
CONFIG_HAVE_GPIO_BITBANGING=y
CONFIG_INLINE_STEPPER_HACK=y
@vladbabii Tried your built firmware, same problem.
@BlackStump - if you use a firmware compiled on an RPi (eg, klipper.bin.gz - stm32f103, revision 49779f13, 28KiB ), does it boot?
-Kevin
@KevinOConnor no same result as compiled on the beaglebone black Unable to open port: [Errno 2] could not open port /dev/serial/by-path/platform-musb-hdrc.1-usb-0:1:1.0: [Errno 2] No such file or directory: '/dev/serial/by-path/platform-musb-hdrc.1-usb-0:1:1.0'
@BlackStump - Okay, thanks. It would seem there is some confusion on the past errors, and/or this is a different error from the previous issues. It doesn't seem you setup is impacted by compiler version. Do you know what the last working version was? Does c930fc3 work for you (eg, klipper-c930fc39.bin.gz - stm32f103, revision c930fc39, 28KiB)?
@vladbabii - You said you were able to get a recent version of Klipper working on the mini when compiling on an RPi - can you provide a klipper log file from that installation?
-Kevin
@KevinOConnor c930fc39 also fails using the bin that you supplied
@KevinOConnor i had bad luck with micro sd cards - need to buy again one. I don't have access to printer but the klipper log file says
Git version: 'v0.7.0-418-gd7e1061'
I will post more information in about 6-7 hours.
@KevinOConnor the last revision that is working so far is 9335cc compiled on the BBB I have not tested anything between that and the latest that fails
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 9.4 (stretch)
Release: 9.4
Codename: stretch
git clone https://github.com/KevinOConnor/klipper .
make clean
git describe --tags
> v0.7.0-833-g49779f1
make menuconfig
dmesg
[87349.765946] usb 1-3.1: new full-speed USB device number 15 using ehci-pci
[87349.946071] usb 1-3.1: device descriptor read/64, error -32
[87350.234049] usb 1-3.1: device descriptor read/64, error -32
[87350.522039] usb 1-3.1: new full-speed USB device number 16 using ehci-pci
[87350.702035] usb 1-3.1: device descriptor read/64, error -32
[87350.989954] usb 1-3.1: device descriptor read/64, error -32
[87351.098267] usb 1-3-port1: attempt power cycle
[87351.801982] usb 1-3.1: new full-speed USB device number 17 using ehci-pci
[87352.218053] usb 1-3.1: device not accepting address 17, error -32
[87352.398064] usb 1-3.1: new full-speed USB device number 18 using ehci-pci
[87352.814185] usb 1-3.1: device not accepting address 18, error -32
[87352.814397] usb 1-3-port1: unable to enumerate USB device
Does not work. Firmware attached klipper_v0.7.0-833-g49779f1-20190911_221538-bennyprinter.zip
same pi
git checkout v0.7.0-775-g078d278
git describe --tags
v0.7.0-775-g078d278
make clean
make menuconfig
make
dmesg
[87861.686614] usb 1-3.1: new full-speed USB device number 19 using ehci-pci
[87861.866713] usb 1-3.1: device descriptor read/64, error -32
[87862.154634] usb 1-3.1: device descriptor read/64, error -32
[87862.442644] usb 1-3.1: new full-speed USB device number 20 using ehci-pci
[87862.622451] usb 1-3.1: device descriptor read/64, error -32
[87863.150658] usb 1-3.1: device descriptor read/64, error -71
[87863.258867] usb 1-3-port1: attempt power cycle
[87863.962671] usb 1-3.1: new full-speed USB device number 21 using ehci-pci
[87864.002201] usb 1-3.1: New USB device found, idVendor=2341, idProduct=abcd
[87864.002214] usb 1-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[87864.002220] usb 1-3.1: Product: Klipper firmware
[87864.002226] usb 1-3.1: Manufacturer: Klipper
[87864.002231] usb 1-3.1: SerialNumber: 12345
[87864.009436] cdc_acm 1-3.1:1.0: ttyACM0: USB ACM device
Klipper connects, the error below is normal because this is a spare empty board, not the one i use normally.
Unable to read tmc uart 'stepper_x' register IFCNT
Once the underlying issue is corrected, use the "RESTART"
command to reload the config and restart the host software.
Printer is halted
Klipper state: Not ready
klipper.v0.7.0-775-g078d278.zip
Attached file with firmware.
v0.7.0-775-g078d278 on lubuntu desktop, same steps as my prior post
Distributor ID: Ubuntu
Description: Ubuntu 18.04.3 LTS
Release: 18.04
Codename: bionic
Surprinzingly, clean dmesg with no errors compared to one compiled on pi 3b. Klipper connects with the proper error (as i mentioned above, it's a test board with no steppers).
Unable to read tmc uart 'stepper_x' register IFCNT
Once the underlying issue is corrected, use the "RESTART"
command to reload the config and restart the host software.
Printer is halted
Klipper state: Not ready
@anm8tor & @basriram - You can find above 2 working firmwares for the skr mini 1.1
@KevinOConnor let me know if you need something else for me to run.
@vladbabii i'll give it a try, but doing more research and knowing that I am running 2208 drivers, I'm not sure it will be worth it. I can at least test USB communication
v0.7.0-833-g49779f1 (latest) on lubuntu desktop, same steps as my prior posts
Distributor ID: Ubuntu
Description: Ubuntu 18.04.3 LTS
Release: 18.04
Codename: bionic
klipper.v0.7.0-833-g49779f1.lubuntu.zip
Doesn't work.
@vladbabii i'll give it a try, but doing more research and knowing that I am running 2208 drivers, I'm not sure it will be worth it. I can at least test USB communication
@anm8tor TMC 2208 and 2209 work on skr mini firmware builds above, with UART.
@KevinOConnor I have narrowed it down to https://github.com/KevinOConnor/klipper/commit/c380d4639b61042e53e1c2b98c3f45105f55bbf0 works
https://github.com/KevinOConnor/klipper/commit/7031202e7c2c7f96eb351399f629d718e7733388 fails to find the usb
Well, that's certainly a surprising result. Can you attach the Klipper log files from the successful boots?
My suspicion is that the bootloader on the skr mini is flaky and is not actually deploying the binaries correctly. (Either randomly not deploying, or perhaps it is scanning for something in the binary that is randomly passing.)
Probably the best way to determine if that is the case is to hook up the SWD lines to a Raspberry Pi and run OpenOCD to debug the situation.
-Kevin
@KevinOConnor c380d46.log 7031202.log
@KevinOConnor I used commit https://github.com/KevinOConnor/klipper/commit/49779f13a23be766b3a131a285f7fb5447488c74 which failed to boot the skr mini but reverted src/stm32/gpio.h src/stm32/spi.c to before https://github.com/KevinOConnor/klipper/commit/7031202e7c2c7f96eb351399f629d718e7733388 and it boots klippy.log
@BlackStump - FYI, none of the spi.c code is run until after host and mcu have successfully connected. This looks to me like it just happened to result in a slightly different code layout which the bootloader accepted.
-Kevin
@KevinOConnor Is it possible to replace the flaky bootloader with a sane one? or what is the solution going forward?
It is possible to replace the bootloader via the serial port - there's some details in docs/Bootloaders.md. That's not a particularly good option for most users, so finding the root cause on the skr mini is probably a good thing - I suspect that will require someone with the device to debug it via a hardware debugger (eg, OpenOCD).
-Kevin
FYI, I was able to boot the klipper-bad.tar.gz image from https://github.com/KevinOConnor/klipper/issues/1884#issuecomment-529770691 on my stm32f103 test board. So, this definitely seems like the bootloader isn't writing the firmware correctly.
If someone has an image that doesn't boot, they could try reading out the rom via the serial port (wire up the serial port to an rpi, set the boot0 pin high, reboot, run stm32flash -r image.bin /dev/ttyAMA0
). Then see how the image that actually got written differs from the requested image.
Another simple test would be to see if padding helps. Run head -c 4096 /dev/zero > pad4k.bin ; cat out/klipper.bin pad4k.bin > firmware.bin
and then flash resulting firmware.bin file.
-Kevin
@KevinOConnor I just tried the padding option, alas still does not boot .
Can someone tell me which pins are the serial ones for skr mini? Are they 5v or 3.3v? I want to try to do some tests myself.
The serial pins are the RX0/TX0 on the "TFT" header. The SWD pins are the SWDIO/SWCLK pins on the "ICSP" header. Those pins (but not all the pins on the given header) should be 3.3V.
-Kevin
@KevinOConnor would i be able to upload a new firmware via the serial pins if i use a serial cable? Or do i need to also change bootloader?
I'm having the same issue on a SKR Mini E3 DIP. Like BlackStump I was able to bisect the issue down to commit 7031202.
Reverting that commit makes the USB connection work. I was trying to nail down the cause in the commit and commented out the entries in the spi_bus array in src/stm32/spi.c, so the array is empty. This makes the USB connection work also.
I was wondering whether the array entries being present somehow mess with the memory layout and wanted to keep them around without being used, but I think then the array and its entries got optimized out of the image. I also tried removing the static modifier from the array to get it in a different linker section and make it end up at a different address, but that also led to an unusable image. Not sure if that would even cause it to end up in a different linker section, but I think that makes my memory layout hypothesis less likely.
@vladbabii: You should be able to write to the flash over serial. stm32flash -w klipper.bin -S 0x8007000 I'm not 100% sure about the address though. I can't use stm32flash currently, otherwise I'd try myself. Make sure you do a full dump of the flash before, so you can restore your bootloader in case you accidentally overwrite it.
I can't use stm32flash currently, otherwise I'd try myself.
FYI, if wiring the stm32 chip to a Raspberry Pi, be sure to read the notes at: https://www.klipper3d.org/Bootloaders.html#stm32f103-micro-controllers-blue-pill-devices
-Kevin
resetting without sd card and with sd card with firmware on it - output on serial port
Please Checking!
sd Init card error!
Please Checking!
sd Init card error!
Please Checking!
sd Init card error!
Please Checking!
sd Init card error!
Please Checking!
res=3
SD ⸮⸮⸮⸮⸮⸮ʧ⸮ܣ⸮⸮⸮⸮⸮
Firmware Update Fail⸮⸮⸮⸮⸮⸮
F_open: fr = 3 > FR_NOT_READY
-----------------O K--------------------
SD ⸮⸮⸮⸮⸮سɹ⸮⸮⸮⸮⸮⸮⸮
Total Size: 14901 MB
Free Size: 14900 MB
⸮⸮⸮⸮⸮⸮BootLoader
⸮⸮⸮ļ⸮⸮ɹ⸮
⸮⸮⸮⸮⸮ļ⸮⸮⸮С⸮⸮ 16764 Byte
bw= 2048
⸮⸮⸮⸮д⸮⸮...
bw= 2048
⸮⸮⸮⸮д⸮⸮...
bw= 2048
⸮⸮⸮⸮д⸮⸮...
bw= 2048
⸮⸮⸮⸮д⸮⸮...
bw= 2048
⸮⸮⸮⸮д⸮⸮...
bw= 2048
⸮⸮⸮⸮д⸮⸮...
bw= 2048
⸮⸮⸮⸮д⸮⸮...
bw= 2048
⸮⸮⸮⸮д⸮⸮...
bw= 380
дflash⸮⸮⸮
Flash Updata Finsh !!!
⸮⸮Ҫ⸮⸮⸮⸮⸮⸮byby !!!
-----------------O K--------------------
D ⸮⸮⸮⸮⸮سɹ⸮⸮⸮⸮⸮⸮⸮
Total Size: 14901 MB
Free Size: 14900 MB
⸮⸮⸮⸮⸮⸮BootLoader
F_open: fr = 4 > FR_NO_FILE
Firmware has been updated! or File no existence! Please check file in SD Card!
I'm using a serial cable with 3.3 pins / 5v tollerant. I power the board via usb and user serial cable to with /dev/ttyUSB0 connected to RX/TX pins
stm32flash -r image.bin /dev/ttyUSB0
stm32flash 0.5
http://stm32flash.sourceforge.net/
Interface serial_posix: 57600 8E1
Failed to init device.
This is my first time working with a stm32 device so if you can point me in the right direction i would be grateful. Thank you
In order to enter the bootloader it is necessary to pull the BOOT0 pin high. Alas, it looks like that board has the BOOT0 pin permanently tied low. Simplest solution is probably to wire up openocd on an rpi and use that mechanism to debug (as described at https://www.klipper3d.org/Bootloaders.html#running-openocd-on-the-raspberry-pi ).
Separately, was your firmware.bin file exactly 16764 bytes and was this a failure binary?
-Kevin
What was the verdict on this issue? I wanted to add that I'm experiencing the same symptoms as @vladbabii, and that reverting to commit c380d463 worked.
More details:
I replaced my Ender 3 board yesterday with an SKR Mini E3 DIP, which has the STM32F103 RET6 chip on it. I did a git pull (which brought my repo up to 9fcd3e7), and did a make menuconfig, my selections:
[*] Enable extra low-level configuration options
Micro-controller Architecture (STMicroelectronics STM32F1/F4) --->
Processor model (STM32F103) --->
Bootloader offset (28KiB bootloader) --->
Clock Reference (8Mhz crystal) --->
[*] Use USB for communication (instead of serial)
USB ids --->
(0x2341) USB vendor ID
(0xabcd) USB device ID
(12345) USB serial number
[ ] Specify a custom step pulse duration
(!PC13) GPIO pins to set at micro-controller startup
I then built it and copied to the SD card as firmware.bin. I powered up the printer, and this is what dmesg said
[331892.854343] usb 1-1.3: USB disconnect, device number 20
[331932.569391] usb 1-1.3: new full-speed USB device number 21 using dwc_otg
[331932.669376] usb 1-1.3: device descriptor read/64, error -32
[331932.889393] usb 1-1.3: device descriptor read/64, error -32
[331933.109363] usb 1-1.3: new full-speed USB device number 22 using dwc_otg
[331933.209370] usb 1-1.3: device descriptor read/64, error -32
[331933.429366] usb 1-1.3: device descriptor read/64, error -32
[331933.549502] usb 1-1-port3: attempt power cycle
[331934.209356] usb 1-1.3: new full-speed USB device number 23 using dwc_otg
[331934.649356] usb 1-1.3: device not accepting address 23, error -32
[331934.749370] usb 1-1.3: new full-speed USB device number 24 using dwc_otg
[331935.189353] usb 1-1.3: device not accepting address 24, error -32
[331935.189493] usb 1-1-port3: unable to enumerate USB device
After finding this github issue, I confirmed that these two work:
c176b66 c380d46
And dmesg looks much happier.
[332554.655152] usb 1-1.3: new full-speed USB device number 27 using dwc_otg
[332554.789574] usb 1-1.3: New USB device found, idVendor=2341, idProduct=abcd
[332554.789591] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[332554.789600] usb 1-1.3: Product: Klipper firmware
[332554.789608] usb 1-1.3: Manufacturer: Klipper
[332554.789616] usb 1-1.3: SerialNumber: 12345
[332554.858160] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
[332554.859711] usbcore: registered new interface driver cdc_acm
[332554.859722] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
I'm willing to help test if you guys need an additional tester with an stm32 board.
Do I understand correctly that the klipper does not work on skr dip? For two days I can’t connect the board. One of the problems, I can not figure out the pins ( If anyone succeeds, please share the configuration file
One of the problems, I can not figure out the pins
@qldestlp which pins are you not able to figure out?
I've attached my config here. The setup is probably different than yours, this is the E3 Mini DIP with 4 TMC2208 drivers in UART mode (single wire mode), and a BLtouch.
My understanding is this issue is stalled until a developer can attach a hardware debugger (eg, openocd) to a board to diagnose what the underlying issue is.
If someone wants to install OpenOCD (see docs/Bootloader.md) on a Raspberry Pi, route the corresponding SWDIO/SWCLK/RESET/GND wires to the board and then give me ssh access to that Raspberry Pi, then I can try to take a quick look. I can't make any guarantees though.
-Kevin
compiled with latest version - effe6f6ddd5132db4ab4f88bf8616aab575e7691
Dmesg output when connecting to usb
With this version everything works fine - c176b66f291371e8ba1c171e56bb2a0416ccf16f
I will try to compile with newer versions than above and see when things broke, and will post here with results. As far as can tell it should be about when make menuconfig added options for different cpu types for STM32F103
Please let me know what information i can provide, since klipper logs is useless because the service is not even started.
Tested this on pi 3b+, pi4 ajnd lubuntu 18.04
Thank you