Getting Klipper -> MCU comms working with Creality V4.0.1 mainboard ( CR-100 )

General Discussion
1

Basic Information:

Printer Model: Creality CR-100
MCU / Printerboard: STM32F103 / Creality 3D v4.0.1
Host / SBC: x86 / Debian 6
klippy.log
klippy(7).log (202.5 KB)

I’m trying to get Klipper working with the Creality 3D v4.0.1 mainboard and have gotten to the point where Klipper server is attempting to communicate with Klipper firmware, but I’m not getting any response from the MCU.

I’ve been given a Creality CR-100 printer, and thought I’d give it the Klipper treatment. To my surprise it runs a v4.0.1 mainboard, in many ways similar to the v4.2.2 boards my Ender 3 printers run.

I’ve spent a bit of time tracing and buzzing circuits to fill out a first-attempt printer.cfg, and have made several guesses on firmware configuration for the image that I’m flashing (see attached .log). I have confirmed that the CH340G TX pin goes to PA10 and RX to PA9.

However while Klipper is connecting to the right device and I can see the incoming comms (Creality changed their LED on later boards to show the outbound traffic, but on this board it shows the inbound traffic) via LED and logic probe, the MCU doesn’t respond.

[Saleae Logic screengrab removed; my post count is too low]
The top trace is the CH340G TX pin, the middle trace is the CH340G RX, and the lower trace is the CH340G DTR pin.

I’ve also confirmed that the bootloader is intact (as best I can) by flashing stock FW back to the printer to confirm USB serial comms via Creality Slicer.

[Saleae Logic screengrab removed; my post count is too low]
The top trace is the CH340G TX pin, the middle trace is the CH340G RX, and the lower trace is the CH340G DTR pin.

This feels like a simple config error that I haven’t managed to identify; I’d appreciate any input you can provide.

2

Saleae_Screengrab_StockFW_CrealitySlicerControl
Saleae_Screengrab_StockFW_CrealitySlicerControl891×472 10.9 KB

USB Serial Comms behaviour with stock FW. The top trace is the CH340G TX pin, the middle trace is the CH340G RX, and the lower trace is the CH340G DTR pin.

3

Saleae_Screengrab_Klipper_FirmwareRestart
USB Serial Comms behaviour with Klipper FW. The top trace is the CH340G TX pin, the middle trace is the CH340G RX, and the lower trace is the CH340G DTR pin.

4

Without owning the board and investing a lot of time in tracing back each pin, it is quite difficult to support in a meaningful way.

Some boards even do weird things like requiring a certain pin being pulled high or low for it to work properly.

It seems that there are not even any Marlin sources available for this board. This might provide some necessary insights.

5

Yes, appreciated! It’s not a popular board by any stretch of the imagination.

Even so, I have the board and I’ve done a first pass at mapping the circuit. I’m happy to do the legwork in my downtime.

Did anyone make a “developer diary” while bringing up any of the previous boards from scratch?

6

The most obvious difference in the comms path between this board and the later v4.2.2 schematic is the use of the CH340G DTR signal; on the later boards this is run to PA8, but on this board PA8 goes to the IR module and DTR doesn’t make it to the MCU.

Is DTR used in the Klipper FW while initiating comms?

7

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.