Thanks for doing amazing work on klipper.
I’ve been trying to make klipper work on bluepill boards (stm32f103c8t6) and there is no luck in this regard
I built the firmware with following config and installed on bluepill using st-link.
stm32f1 enumerates over usb but it does not give a response to the commands coming from klippy.
$ ~/klippy-env/bin/python ./klippy/console.py -b 115200 /dev/ttyACM0
..
..
==================== attempting to connect ====================
INFO:root:Starting serial connect
INFO:root:Timeout on connect
ERROR:root:Wait for identify_response
Traceback (most recent call last):
File "/home/ami/klipper/klippy/serialhdl.py", line 75, in _get_identify_data
params = self.send_with_response(msg, 'identify_response')
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/ami/klipper/klippy/serialhdl.py", line 271, in send_with_response
return src.get_response([cmd], self.default_cmd_queue)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/ami/klipper/klippy/serialhdl.py", line 331, in get_response
self.serial.raw_send_wait_ack(cmds[-1], minclock, reqclock,
File "/home/ami/klipper/klippy/serialhdl.py", line 263, in raw_send_wait_ack
self._error("Serial connection closed")
File "/home/ami/klipper/klippy/serialhdl.py", line 68, in _error
raise error(self.warn_prefix + (msg % params))
serialhdl.error: Serial connection closed
[Oct23 12:18] usb 3-3.3.1: new full-speed USB device number 112 using xhci_hcd
[ +0.099155] usb 3-3.3.1: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
[ +0.000005] usb 3-3.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0.000001] usb 3-3.3.1: Product: stm32f103xe
[ +0.000001] usb 3-3.3.1: Manufacturer: Klipper
[ +0.000001] usb 3-3.3.1: SerialNumber: B55B5A1A000000007A9EEE01
[ +0.008449] cdc_acm 3-3.3.1:1.0: ttyACM0: USB ACM device
I debugged a bit and found following things in command.c
// Find the next complete message block
int_fast8_t
command_find_block(uint8_t *buf, uint_fast8_t buf_len, uint_fast8_t *pop_count)
{
static uint8_t sync_state;
if (buf_len && sync_state & CF_NEED_SYNC)
goto need_sync;
if (buf_len < MESSAGE_MIN)
goto need_more_data;
uint_fast8_t msglen = buf[MESSAGE_POS_LEN];
if (msglen < MESSAGE_MIN || msglen > MESSAGE_MAX)
goto error;
uint_fast8_t msgseq = buf[MESSAGE_POS_SEQ];
if ((msgseq & ~MESSAGE_SEQ_MASK) != MESSAGE_DEST)
goto error;
if (buf_len < msglen)
goto need_more_data;
if (buf[msglen-MESSAGE_TRAILER_SYNC] != MESSAGE_SYNC)
goto error;
uint16_t msgcrc = ((buf[msglen-MESSAGE_TRAILER_CRC] << 8)
| buf[msglen-MESSAGE_TRAILER_CRC+1]);
uint16_t crc = crc16_ccitt(buf, msglen-MESSAGE_TRAILER_SIZE);
if (crc != msgcrc)
goto error;
sync_state &= ~CF_NEED_VALID;
*pop_count = msglen;
// Check sequence number
if (msgseq != next_sequence) {
// Lost message - discard messages until it is retransmitted
goto nak;
}
next_sequence = ((msgseq + 1) & MESSAGE_SEQ_MASK) | MESSAGE_DEST;
return 1;
if (msgseq != next_sequence) {
// Lost message - discard messages until it is retransmitted
//<---- this is where it fails
goto nak;
}
I’ve tried with different cables and got the same issue. I wonder if it’s a known issue.




