On SKR mini v 1.1 and latest klipper - issues device descriptor read/64, error -32 #1884
Comments
|
klippy.log |
|
There's been a bunch of changes to the stm32 code recently. However, the USB support on the stm32f103 was not changed. The config options have changed a bit, though, so make sure you have a clean checkout, be sure to rerun "make menuconfig", and make sure the appropriate config settings are in place (basically, select stm32f103, 28KiB bootloader, and otherwise use the defaults). If you continue to have issues, can you attach your .config file here? -Kevin |
|
I believe the printer config file doesn't really matter because the USB serial connection is not detected on the OS level for the klipper software be able to use it. I have attached it here. The printer is It's a testing platform for the X/Y part of Corexy and it moves and works corectly with the firmware version mentioned above. I will re-compile from latest in about 8 hours hours. If its any help I can provide remote ssh access to a pi or laptop connected to that board and can help you debug. I have used the 28kb bootloader and noticed the change in the menuconfig options - that prompted me to try older klipper versions because when i bought the mini boards (about one and a half months ago) i managed to get it running with the older menuconfig options. |
then selected microcontroller "stmicroelectronics stm32f1/f4" then selected processor model stm32f103 then selected booloader offset 28kib left default 'use usb for communication (instead of serial)' usb ids:
got this error now (this is new) made sure all settings remained then ran make put file on microsd card and powered on board with 12v power and no usb then shutdown 12v power, removed microsd and check if a file BIGTREETECH.bigtreetech is there - and it was Now ran to clean dmesg output from linux. Then plugged usb wire back into the board next, ran dmesg -c and powercycled the board (12v off, 10 second wait, 12v on dmesg output: |
|
Next, reverted to old working firmware via sd card upload and repowered the board: Dmesg output: This is on the same machine with everything the same (cable, usb port, board, etc). |
|
@KevinOConnor please let me know what else to try. Do you know on which revision the build menu for this processor changed? I'd like to make a build before and one after to see if that is the cause or something else. Thank you for your time! |
|
Can you attach the ".config" file from the failed build? (It is a file produced by "make menuconfig" - it should be in ~/klipper/.config .) -Kevin |
|
dot.config.zip |
|
And this is from the working one - c176b66 |
|
Can you retry with the latest code (commit c930fc3)? -Kevin |
|
In 5 minutes |
stm31f1/f2 -> smt32f103 -> 28kib .config contents: make command... dmesg output with toggle power off to on dmesg output with replugging in the usb cable |
|
A separate user was reporting that if they hit the reset button a couple of times, it would eventually come up. (Though that user also reports the latest version does boot on its own.) Do you eventually see a connection when clicking reset? -Kevin |
|
I will try that but in a couple of hours. Is the reset press required every boot? Because with older firmware it always connects to usb no matter what. |
|
Done a ton of resets. No change. same errors ( -62 ). Tried different cables, different ports, a laptop, a desktop, a pi, a usb 1.1 hub, a usb 3.0 hub.... |
|
Alas, I'm unable to reproduce the problem, so it's difficult to track this down. Are you able to successfully compile and run ec3d865 ? If so, can you provide the klipper log file from that run? I put some code changes up on the work-stm32f1-20190820 branch: You could try with that branch - but the changes on that branch are just wild guesses at this point. -Kevin |
|
trying ec3d865 config file This one works |
|
work-stm32f1-20190820 branch config: this one does not work |
|
Should i try revisions after ec3d865 until i find one that does not work? |
|
I will try building a couple more firmware versions after the one mentioned above and see what happens. |
|
@KevinOConnor can i use some other 2 pins for serial communication instead of usb port? I think that might solve things temporarily if the USB connection is the only issue. |
|
I got some files from another user on discord that uses this fork Git: https://github.com/BlackStump/klipper This works on my board |
|
compiling on a pi 3b+ and on a ubuntu 18.04 produce different files for same git revision
Revision 078d278 |
The mini has a "tft" header that seems to expose uart pins. So, you should be able to disable USB support in "make menuconfig" and use a regular serial port instead. If you do this, be sure the voltages match correctly.
Different versions of gcc produce slightly different code. It's normal. -Kevin |
|
@KevinOConnor compiling for skr mini works only on raspberry pi or arm systems. I'll leave this ever if anyone happens to have the same issue. I think for now we can close this ticket? Or should I leave it open due to different behaviour of firmware depending on where it was compiled? |
|
Can you provide more details? Are you now able to boot the latest code on the mini? What OS is unable to correctly compile Klipper? Is that system able to compile an older version of Klipper? -Kevin |
|
This system cannot make workable firmwares: On this pi builds work: |
I had a problem with uart and tx pins. In the end, I left only uart. I tried your config. But the miracle did not happen. I can’t imagine where I was wrong. |
|
@KevinOConnor @vladbabii Did you guys manage to get any debugging done for this issue? |
|
I'm tryng to figure out the skr mini 1.1 pins and openocd config file - openocd starts then shuts down right now Do i need to connect sck/sdo pins on the icsp header ? Or the ones rx/tx next to board corner ? The reset pin i asume is the RST in the corner, in the row with +5v,gnd,tx,rx,rst I also have this cable, could i use this instead of direct wiring? - https://www.adafruit.com/product/954 OpenOCD config - not sure what i should put here |
|
@KevinOConnor helped me, below is the openocd config that works. The bcm2835gpio_.. lines were needed for pi 4 |
|
I apologize if this is a dumb question but is this issue with the SKR mini 1.1 limited to attempts to flash the firmware from the sdcard, or does it affect directly flashing over USB as well? I recently installed an SKR mini 1.1 as a secondary MCU and got it up and running using the "known good" build linked in this thread. But now that the firmware is installed, I'm wondering if I can direct-flash update to a more recent build. Or will that reintroduce the USB connection errors? |
|
@theophile I only managed to flash it via SD card. Haven't looked into how to upload via usb yet but might need a different bootloader |
|
Any new findings to this Issue? |
|
Kevin debugged for a while on my pi4 and then we had some issues. I figured out you need a usb 2 hub on a pi4 to get reliable usb connection between a mini and pi4. The test platform is still up and Kevin said he will be also ordering a mini to test things on. I am trying to figure out now how to replace the bootloader (new to openocd and these tools) and try to see if that makes a difference. I will post here if I have anything new. |
|
@vladbabii thanks very mucht for your feedback. |
|
Apologies for the lack of logs/data etc, but I just wanted to say I have had similar issues, and with help from a few people managed to resolve using ec3d865.
|
|
Those with an SKR Mini (and similar) should retry with the latest code (commit 1e8582e). -Kevin |
|
I don't know if it's related or not, but when I try to update an SKR mini 1.1 using "make flash" I get this error: |
|
@KevinOConnor Can confirm it connects on SKR MINI E3 V1: |
|
@theophile Flashing through USB does not work on SKR MINI for now. Copy the |
|
I can confirm that commit 1e8582e fixes the USB connection issue on an SKR Mini E3 DIP, too. |
|
@KevinOConnor i can confirm lastest commit 1e8582e works with mini 1.1 Testing the board now... |
|
skr mini v1.2 board is working with latest pull from git, but using |
|
Connecting to |
No, I don't know why the old code sometimes worked. It's possible some obscure race was allowing the usb packet memory to function long enough and/or some obscure race resulted in a well timed reset after enabling the usb clock.
The bootloader on the skr mini does not support writes by usb. Follow the directions at the top of config/generic-bigtreetech-skr-mini.cfg to flash. -Kevin |
|
@KevinOConnor would changing bootloader make the board capable of upload firmware via usb ? or maybe using openocd ? |
|
Myself and some others have replaced the bootloader with the stm32duino bootloader which does support flashing over usb. Specifically this file was used: https://github.com/rogerclarkmelbourne/STM32duino-bootloader/raw/master/bootloader_only_binaries/generic_boot20_pb7.bin As a general notice, replacing the bootloader is an advanced option - there is some info in docs/Bootloaders.md, but be sure you are comfortable with the operation and are confident you can restore the old bootloader before proceeding. -Kevin |
|
@KevinOConnor What's required hardware-wise to flash the new bootloader? I imagine this is the approach to take? https://github.com/KevinOConnor/klipper/blob/master/docs/Bootloaders.md#stm32f103-with-stm32duino-bootloader Anybody else willing to share the actual steps (ideally with pics if applicable?) |
|
Once i manage to figure out all the steps I will post here unless someone beats me to it. |
|
I'm going to close this ticket as it appears the original issue has been resolved. -Kevin |
|
@vladbabii, were you able to successfully flash a USB-capable bootloader to the mini 1.1? If so, could you share your steps? Thanks! |
|
@vladbabii, just wanted to check in with you and see if you were able to flash a USB-capable bootloader to the SKR Mini v1.1? If so, what was your procedure? |
compiled with latest version - effe6f6
Dmesg output when connecting to usb
With this version everything works fine - c176b66
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
The text was updated successfully, but these errors were encountered: