SKR mini e3 v2 Not found after update

General Discussion
1

After updating to v0.10 I can no longer detect my MCU. I have tried reflashing, have verified the settings are correct from the config. I have asked on discord but have not found a solution. Out of ideas what to try next.

image

Edit: looks like I am not the only one getting this error. From Reddit: https://www.reddit.com/r/klippers/comments/q3n3ql/cant_find_serialid_using_a_skr_mini_e3_v20/?utm_source=share&utm_medium=ios_app&utm_name=iossmf

2

Do a step by step analysis:

  • Unplug and replug USB
  • Run dmesg and you should see some information on a new USB device or potentially on some errors. Post it here
  • Run ls /dev/serial/by-id/* and post the results here
  • Post your klipper log
3

Nothing registers in dmesg when plugging/unplugging the USB.
pi@fluiddpi:~/klipper $ ls /dev/serial/by-id/*
ls: cannot access ‘/dev/serial/by-id/*’: No such file or directory
Klipper log just complains about invalid MCU.

4

This means that the Linux Operating System does not “see” your SKR. Potential reasons:

  • Defect USB cable
  • Defect USB port (on SKR or Pi side)
  • Other hardware related defects
  • Other issues with the Pi like defect Pi SD card
  • Problem with the firmware on the SKR

Possible solutions:

5

I have tried all of the above steps. Like I said, after updating the firmware these problems occurred. I can confirm that flashing the firmware changes to firmware.cur. I have re-imaged my pi multiple times. Something changed in the firmware that is being flashed to the SKR that is breaking this.

6

Surely possible that it is a regression but on the other hand I would have expected more issues like yours if it is a general thing.

If it is the case, then you can always go back to an older git version and try. E.g.:

git checkout 3176150050b666a582ac0993dc14e6663133ecb9
make distclean
make menuconfig
make

This will bring you to a commit at beginning of August. To revert back to latest master issue:

git checkout master
7

pi@fluiddpi:~/klipper $ ls /dev/serial/by-id/*
/dev/serial/by-id/usb-Klipper_stm32f103xe_39FFD4054255373722511757-if00

Its back!! So how do we figure out what is broken?

8

Now you would have to find the commit, which broke things. Obviously it is somewhere between beginning of August and release of v0.10.

Here the git bisect command can come in handy but it requires some effort on your side. This command will always use a version halfway between a last-known good and a known bad. See here for a nice tutorial: A beginner's guide to GIT BISECT - The process of elimination

After you have identified where things go wrong someone with coding knowledge (e.g. @koconnor) would have to analyze your finding.

9

Bummer, this might be where it ends for me then. I would need a lot of assistance even locating the latest commit. I don’t understand how this is not a more widespread issue, I have a very common board. Thank you for your assistance. If I become braver, I’ll stumble down the git bisect route. Hopefully, this thread can continue to help other people.

10

Had a friend walk me through git bisect.

This was the final outcome

7f82dcb442596959c667d0ed8f19e39af3f94b0d is the first bad commit
commit 7f82dcb442596959c667d0ed8f19e39af3f94b0d
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Thu Aug 19 14:59:53 2021 -0400

    endstop_phase: Use config.getintlist() for trigger_phase config option

    Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

:040000 040000 8c8ea5abf6da1ee2daa9ce493ae464cd91b952d3 a00105fc01406421e8ee5ef0f37747ca332a4698 M      klippy

Looking at this commit it has nothing to do with why the USB would not work. Weird.

1 Like
11

This is really strange. Would you please reconfirm that

git checkout 58dedb6b16796427466816e0f6f6eaccb464ca87
make distclean
make menuconfig
make
<flash your MCU>

actually works.

And

git checkout 7f82dcb442596959c667d0ed8f19e39af3f94b0d
make distclean
make menuconfig
make
<flash your MCU>

does not work.

The mentioned bad commit does not change the MCU code, so in theory this should absolutely not lead to the issues you are seeing.

12

FWIW, I have a skr-mini-e3-v1.2 and the bootloader is very flaky. Try to write the same image 5 times and the first four fail, but the fifth is accepted. The description above sounds like a “random failure”, you may wish to go back to the master branch and retry the flash a few times.

-Kevin

13

Hello, I have the same problem here suddenly,before i had a long time use. (ls / dev / serial / by ID , can’t find SKR v1.3)，Windows can recognize it , but RPI can’t.
I try to flash different image systems many times ,but it doesn’t work.Today， motherboard is powered on again, the motherboard can be recognized.But RPI can’t recognize it after reboot now :cold_sweat: