Basic Information:
Printer Model: TwoTrees SK1
MCU / Printerboard: custom RP2040 based board
Host / SBC: Custom makerbase skipr like board
I am trying to upgrade klipper software on the TwoTrees SK1 printer, as the stock version is almost 2 years old. I managed to upload new firmware to the toolhead’s microcontroller. The firmware is built with the following parameters:
- No bootloader
- UART communication at 250000
- All other settings are default
The problem is that klipper cannot connect to the toolhead on cold boot. Sometimes it stucks on “mcu ‘MKS_THR’: Starting serial connect” message, sometimes it restarts connection on timeout, but still cannot connect. Surprisingly after a few presses on the toolhead board reset button it eventually connects and works normally.
What could go wrong with this upgrade? How I can troubleshoot the connectivity (to understand whether this is a linux side issue, or the toolhead board problem)
1 Like
Hello @grafalex !
Deleting the line that asks for the klippy.log does not mean you don’t have to provide it.
Please attach it to your next post.
klippy.log (163.9 KB)
.
Here is the log from the cold boot, then a few klipper restarts, tries to reset the board, and eventually it connected.
I’m not overly familiar with that printer but a quick google search told me two important things.
From what I can tell, a version of the MKS_THR is made using the RP2040. This shouldn’t affect it with a cold boot but I’d definitely look at putting a fan on that board ASAP if it is in fact RP2040 based. They heat up QUICK.
Second, I’m assuming since it’s serial you’re connected via USB? Have you tried a different USB cable?
You’re getting timeouts because the board isn’t replying to Klipper quick enough.
mcu ‘MKS_THR’: Timeout on connect
mcu ‘MKS_THR’: Wait for identify_response
There seems to be quite a bit of latency on when the connect command is sent and when it’s reported as received, so my first thought is a wiring problem. I’d try a different cable and see if that helps solve your issue.
Thank you for the response. Here are a few notes:
- There is an always-on fan at the RP2040 board, though it does not heat even without it.
- I am using USB only to upload the new firmware. In the other time the board is connected using the UART.
- The board is connected using a wire installed on the factory, that goes from the main board, through the frame, then through the cable chain to the board. Perhaps it is possible to replace this cable, but this might be complicated, so I need to be absolutely sure this is because of the cable (I am using this printer for about 4 weeks, and it worked fine until I started the upgrade, so I think this wire is the last thing to check). Though I’ll try to connect with another cable.
- It fails on timeout after a few seconds, not miliseconds.
Question: Is there a way to check whether RP2040 boots normally?
Nope those MKS OEM boards and toolheads are using plain uart to the toolheads
@grafalex I personally had the interest to get discord colleges kingroon to the latest version and we had success for kingroon hw version V2.0 (toolhead usb) and the current V2.2 (th serial).
I plan to write a full guide here
The same should be possible with the SK1 too.
Can you make good pics from the toolhead pcb on both sides?
Here are the pics (sorry, this is the best quality I can make)
Thx
Could you just check if
~/klippy-env/bin/python ~/klipper/klippy/console.py /dev/ttyS0 (if that is the same tty as on the KP V.2.2)
also lose the connecton to the THR while build in? (klipper service must be stopped)
Yes, it behaves same way - repeatedly trying to connect.
I did some oscilloscope probing, and see that TX pin (from MCU to the host) value is about 0.6V. I still have no idea what the problem is.
This could be a hardware problem (e.g. broken wire or a connector), but I tried to bend wires and connectors - nothing changes. But sometimes after replugging everything the connection fixes. Sometimes it goes other way - works normally for a long time, then after reboot breaks.
This tends me to think, that this could be also a RP2040 initialization issue. For some reason the microcontroller does not start, or does not initialize UART properly.
So there is a question: is there a way to verify microcontroller works normally? It would be nice to understand somehow whether this is MCU issue, or the host side one.
Did you have any issues when flashing? If it went into dfu mode and accepted the firmware that’s a decent sign it’s working. Can you post a screenshot of the menuconfig options you used when flashing?
Flashing was always working normally. Though I am not sure this is a classic USB DFU - when in boot mode the RP2040 exposes a mass storage device, where I just copy the firmware to.
Taking into account that sometimes it works, I come to a conclusion that firmware update goes normally. The question is why it does not start normally for most of the time.
Here is the configuration screenshot.
That’s how the RP2040 is designed, so that’s right.
I’ll let docgalaxy help you, I can’t find any meaningful info on those boards and he seems to be familiar with them.
Year it could be an hardware problem …
But the best way imo is to get the manufacture fw on the toolhead. We need somebody that still has it to extract it but I am unfamiliar with this on rp2040. Did this with the many STM32s already and the Kingroon was one where it worked flawlessly to get the offset out of the dumped bin.
I need to check TT Support page and downloads to take a look if they provide the file there.
Lets see if I find time on wednesday or thursday evening for that
@grafalex What happens if you use some shorter jumper cables to connect the toolhead to the board.
Same behavior?
Thats kind of a janky board to be honest, I tried to visually follow the path to the serial connector but GPIO0 and GPIO1 are facing AWAY from it and I don’t see any vias that are headed that way.
That doesn’t necessarily mean anything, it’s just a weird PCB design.
Also, They couldn’t have included a legit USB connector?
The official firmware, surprisingly, is Klipper. That is why I am here.
Though I tried to flash the stock version, and have the same problem.
Unfortunately I do not have right connectors laying around, and there are no such connectors in local stores either. Need to order on Aliexpress, which will take some time. Though I’ll try to make invent somethig on this.
What do you mean? The USB pin header can be wired to a USB connector no problem.
How many people have spare pin header to USB cables laying around? I have 35+ years of electronics parts, cables, wires etc. and probably have maybe 2 pin headers to USB connectors that I salvaged from something else.
They’re not very common. So what happens if you lose one? or it breaks on the USB side?
What is ULTRA common though is just a regular USB cable. Just seems like a weird design choice is all I guess.
Hey here they even soldered the headers here. The kingroon boards have only the holes.
Keep in mind those china printers are not designed with upgrading in the future.
They run outdated Buster and ancient klipper & co
Kingroon even modified the moonraker code to disable its update manager completely (they commented out the update check function codeblock) even if you add the update manager to the config.
@grafalex Is the above mentioned moonraker thing also prrsent at the SK1?
An idea I have is to connect the toolboard to a different board over serial and/or connect a generic pico over serial instead of the thr and check if it dropps out there too
1 Like
Well, you are right, that it would be easier if they could solder a regular USB socket. But I had plenty of regular pin headers, and number of spare USB cables which I could simply cut and solder dupont pins. Moreover one can simply solder USB cable directly to pads.
Correct. Though I managed to update all of them. The biggest problem was updating from buster to bullseye, while updating fluidd, moonraker. and klipper was not a big deal. The only proprietary SW component in this printer is Nextion display to Moonraker bridge, but it seems to work fine with the updated Moonraker.
Thanks for the idea, I’ll try.
