I just installed a new SKR 3 EZ board on my SV06 plus. I get to the step of flashing the board and then can’t go further. Before flashing the board, it shows up running lsusb when I put it into DFU mode. After flashing it does not show up at all, the last DMESG result is it disconnecting. The firmware.bin file is renamed to firmware.cur so it believes it was successful at least. I have tried restarting/re-flashing/using different SD cards. I have verified the menuconfig settings are exactly as BTT’s GH says they should be, but get
ls: cannot access ‘/dev/serial/by-id/*’: No such file or directory
and it’s not detected using lsusb either.
I saw the previous known issue with Debian but it appears that was not for Bookworm.
It seems the BTT documentation/fw is wrong or not up-to-date. I can at least see the board now. The BTT documentation/FW is wrong as they released new boards for the SKR 3 EZ and didn’t announce it or update their documentation (see this Github issue, but I didn’t have to buy the device mentioned in the issue, just change the selected board in the menuconfig to the 723 instead of 743 )
…
(old content)
I just was directed on another forum to an open Github issue for BTT; it seems they may have silently released a new board on the SKR 3 EZ that requires different configurations than their own documentation/FW indicates, I am going to test that and will edit this later with the result for anyone else to find if they encounter the same issue.
Glad that you found the issue. I have a SKR 3 and I had the exact same problem. Try to always check the schematic of BTT boards, not the pdf (or even better, the actual board).
Recently I came across a similar issue with an EBB42 board and pin assigment, pdf stated one thing but in reality the microcontroller was routed differently
Thanks for your feedback. This does indeed seem to be a rather poor performance by BTT, who otherwise stand out from the rest with their documentation and information provided.
That would be great, thanks. I found one online but so far no luck. I may have some bad wiring too, unfortunately but sorting out the config is my first step to identifying that.
That’s pretty much what I did; my probe and the homing just is all off for some reason. The probe I had to invert to get to not be constantly triggered, but it doesn’t trigger at all when I do that. I assume my wiring is off somehow but not really sure where to begin figuring out where.
Figured my problem out, the cable for the Z-axis probe had a twist inside the braided cable management sleeve that it came shrouded in so my wires on the probe were reversed without me knowing it.
I do have a new weird problem though which I think stems back to the BTT giving the wrong info. I am constantly getting the warning that the board is configured for 400mhz but running at 401mhz. I found one other example of this same error on here but the person said they just needed some config file that I don’t believe is at all relevant in my c case. I also believe the board I have is supposed to be more than 400mhz (550 I thought?).
I did; apparently from what I have been able to find Klipper is limited to 400mhz currently, so that explains the 400mhz part. Apparently the error I’m getting is due to to a floating point number being converted to an int to do the calculation for the error, so it’s just a rounding error.
That said, it’s super annoying and pops up all the time, I need to see if I can find how to disable that warning or at least make a “if greater than 5mhz” conditional for the warning or something.
Fuck! really weird that you are getting that kind of errors with a normal setup. As I said, I have a similar setup and never had any issues with that. I run Klipper on a Raspberry Pi 4 and now with a 5, and there is no issue with clock frequency.
Could it be a somewhat corrupted Pi OS installation? Have you tried a fresh installation of everything (Pi OS, Kiauh, klipper, etc)?
It has been introduced to give users an indication if they might have build / flashed their firmware with wrong settings. There have been some cases, where the wrong clock settings have been used during building the firmware that lead to a seemingly working system but ridden with strange and hard to diagnose issues.
There are one or two reports that show a frequency with 1 MHz off and Klipper complaining, but overall there seem only rarely any false positives.
It has been introduced to give users an indication if they might have build / flashed their firmware with wrong settings. There have been some cases, where the wrong clock settings have been used during building the firmware that lead to a seemingly working system but ridden with strange and hard to diagnose issues.
It really should be re-coded with a threshold coded in (I.E. off by more than 5mhz or 1% or something) and also if they are going to do math on floating point numbers and then an int comparison, the numbers should be rounded to zero. Looking at my klippy log, the frequency is always around 400600000-something so rounds up to 401… it seems like every person running a board over 400mhz capable will experience this. The error/warning pops up every few minutes it seems and is super annoying.