Octopus Pro mcu 'mcu': Unable to connect

General Discussion
1

Basic Information:

Printer Model: Custom Elegoo Neptune 3 (only frame is stock)
MCU / Printerboard: BTT Octopus Pro

Build file /home/gypsy/klipper/klippy/…/out/klipper.dict(7844): Sun Dec 11 11:29:37 2022
Last MCU build version: v0.11.0-6-g336cc92a
Last MCU build tools: gcc: (15:8-2019-q3-1+b1) 8.3.1 20190703 (release) [gcc-8-branch revision 273027] binutils: (2.35.2-2+14+b2) 2.35.2
Last MCU build config: ADC_MAX=4095 BUS_PINS_i2c1=PB6,PB7 BUS_PINS_i2c1a=PB8,PB9 BUS_PINS_i2c2=PB10,PB11 BUS_PINS_i2c2a=PH4,PH5 BUS_PINS_i2c3=PA8,PC9 BUS_PINS_i2c3a=PH7,PH8 BUS_PINS_spi1=PA6,PA7,PA5 BUS_PINS_spi1a=PB4,PB5,PB3 BUS_PINS_spi2=PB14,PB15,PB13 BUS_PINS_spi2a=PC2,PC3,PB10 BUS_PINS_spi3=PB4,PB5,PB3 BUS_PINS_spi3a=PC11,PC12,PC10 BUS_PINS_spi4=PE13,PE14,PE12 CLOCK_FREQ=168000000 MCU=stm32f429xx PWM_MAX=255 RECEIVE_WINDOW=192 RESERVE_PINS_crystal=PH0,PH1 RESERVE_PINS_serial=PD6,PD5 SERIAL_BAUD=250000 STATS_SUMSQ_BASE=256 STEPPER_BOTH_EDGE=1
Build file /home/gypsy/klipper/klippy/…/out/klipper.elf(1237112): Sun Dec 11 11:29:43 2022
mcu ‘mcu’: Wait for identify_response
Traceback (most recent call last):
File “/home/gypsy/klipper/klippy/serialhdl.py”, line 68, in _get_identify_data
params = self.send_with_response(msg, ‘identify_response’)
File “/home/gypsy/klipper/klippy/serialhdl.py”, line 259, in send_with_response
return src.get_response([cmd], self.default_cmd_queue)
File “/home/gypsy/klipper/klippy/serialhdl.py”, line 316, in get_response
self.serial.raw_send_wait_ack(cmds[-1], minclock, reqclock,
File “/home/gypsy/klipper/klippy/serialhdl.py”, line 251, in raw_send_wait_ack
self._error(“Serial connection closed”)
File “/home/gypsy/klipper/klippy/serialhdl.py”, line 61, in _error
raise error(self.warn_prefix + (msg % params))
serialhdl.error: mcu ‘mcu’: Serial connection closed

The USB C connection stopped working on the Octopus pro so I started using UART2 pins. Now I am afraid the Pins have stopped working. I tested to working wires (checked out fine) then I cut off the headers and replaced heads and retested (Checked out fine). This all was working. When it stopped working and I first saw the mcu ‘mcu’: Unable to connect I recompiled and reflashed octopus pro checking SD card finding .bin changed to .CUR so that is not the issue. I am confident the wiring is correct as the Octopus Pro and Raspberry pi use the same layout with the TX/RX wires already swapped so you do not have to twist the wires. Raspberry Pi powered from Bunk 5V to both 5V GPIO pins. Raspberry pi Ground to Bunk and to Octopus Header pin beside TX/RX pins. Again this was all working till it quit. I am afraid I have a dyeing Octopus Pro.

klippy (5).log (194.5 KB)
moonraker (2).log (170.3 KB)

2

Looks like you’ve configured the device for an 8K bootloader, it should be 32K: Octopus (Pro) Klipper Firmware -

3

I will redo and check back in. Thank you I can not believe I missed this.

4

My Klipper Firmware Configuration is set to bootloader offset (32Kib Bootloader) if the actual file is Set to 8K then I have bigger issues. My Clock Reference is set to (8 Mhz crystal) to match my processor model (STM32F429)

5

Sorry about that. Does the board show up in /dev/ttyXXX or lsusb?

6

gypsy@neptune3l:/dev $ ls /dev/ttyAMA0
/dev/ttyAMA0
gypsy@neptune3l:/dev $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0c45:6369 Microdia USB 2.0 Camera
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
gypsy@neptune3l:/dev $

I do not know that it ever showed up even when it was working. I know several folders/directories are missing and have been on the Pi

gypsy@neptune3l:/dev $ ls
ashmem loop2 ram13 tty14 tty40 ttyAMA0 vcsu4
autofs loop3 ram14 tty15 tty41 ttyprintk vcsu5
block loop4 ram15 tty16 tty42 ttyS0 vcsu6
btrfs-control loop5 ram2 tty17 tty43 uhid vga_arbiter
bus loop6 ram3 tty18 tty44 uinput vhci
cachefiles loop7 ram4 tty19 tty45 urandom vhost-net
cec0 loop-control ram5 tty2 tty46 v4l vhost-vsock
cec1 mapper ram6 tty20 tty47 vchiq video0
char media0 ram7 tty21 tty48 vcio video1
console media1 ram8 tty22 tty49 vc-mem video10
cpu_dma_latency media2 ram9 tty23 tty5 vcs video11
cuse media3 random tty24 tty50 vcs1 video12
disk media4 rfkill tty25 tty51 vcs2 video13
dma_heap mem serial0 tty26 tty52 vcs3 video14
dri mmcblk0 serial1 tty27 tty53 vcs4 video15
fd mmcblk0p1 shm tty28 tty54 vcs5 video16
full mmcblk0p2 snd tty29 tty55 vcs6 video18
fuse mqueue spidev0.0 tty3 tty56 vcsa video19
gpiochip0 net spidev0.1 tty30 tty57 vcsa1 video20
gpiochip1 null stderr tty31 tty58 vcsa2 video21
gpiomem port stdin tty32 tty59 vcsa3 video22
hwrng ppp stdout tty33 tty6 vcsa4 video23
initctl ptmx tty tty34 tty60 vcsa5 video31
input pts tty0 tty35 tty61 vcsa6 watchdog
kmsg ram0 tty1 tty36 tty62 vcsm-cma watchdog0
kvm ram1 tty10 tty37 tty63 vcsu zero
log ram10 tty11 tty38 tty7 vcsu1
loop0 ram11 tty12 tty39 tty8 vcsu2
loop1 ram12 tty13 tty4 tty9 vcsu3

7

New Klipper log
klippy (6).log (323.6 KB)

This was after clean and make new firmware.bin

8

That sucks, hopefully your retailer will let you exchange the board.

9

gypsy@neptune3l:/dev $ ls -la /dev/tty*
crw-rw-rw- 1 root tty 5, 0 Dec 11 14:22 /dev/tty
crw–w---- 1 root tty 4, 0 Dec 11 14:22 /dev/tty0
crw–w---- 1 root tty 4, 1 Dec 11 14:22 /dev/tty1
crw–w---- 1 root tty 4, 10 Dec 11 14:22 /dev/tty10
crw–w---- 1 root tty 4, 11 Dec 11 14:22 /dev/tty11
crw–w---- 1 root tty 4, 12 Dec 11 14:22 /dev/tty12
crw–w---- 1 root tty 4, 13 Dec 11 14:22 /dev/tty13
crw–w---- 1 root tty 4, 14 Dec 11 14:22 /dev/tty14
crw–w---- 1 root tty 4, 15 Dec 11 14:22 /dev/tty15
crw–w---- 1 root tty 4, 16 Dec 11 14:22 /dev/tty16
crw–w---- 1 root tty 4, 17 Dec 11 14:22 /dev/tty17
crw–w---- 1 root tty 4, 18 Dec 11 14:22 /dev/tty18
crw–w---- 1 root tty 4, 19 Dec 11 14:22 /dev/tty19
crw–w---- 1 root tty 4, 2 Dec 11 14:22 /dev/tty2
crw–w---- 1 root tty 4, 20 Dec 11 14:22 /dev/tty20
crw–w---- 1 root tty 4, 21 Dec 11 14:22 /dev/tty21
crw–w---- 1 root tty 4, 22 Dec 11 14:22 /dev/tty22
crw–w---- 1 root tty 4, 23 Dec 11 14:22 /dev/tty23
crw–w---- 1 root tty 4, 24 Dec 11 14:22 /dev/tty24
crw–w---- 1 root tty 4, 25 Dec 11 14:22 /dev/tty25
crw–w---- 1 root tty 4, 26 Dec 11 14:22 /dev/tty26
crw–w---- 1 root tty 4, 27 Dec 11 14:22 /dev/tty27
crw–w---- 1 root tty 4, 28 Dec 11 14:22 /dev/tty28
crw–w---- 1 root tty 4, 29 Dec 11 14:22 /dev/tty29
crw–w---- 1 root tty 4, 3 Dec 11 14:22 /dev/tty3
crw–w---- 1 root tty 4, 30 Dec 11 14:22 /dev/tty30
crw–w---- 1 root tty 4, 31 Dec 11 14:22 /dev/tty31
crw–w---- 1 root tty 4, 32 Dec 11 14:22 /dev/tty32
crw–w---- 1 root tty 4, 33 Dec 11 14:22 /dev/tty33
crw–w---- 1 root tty 4, 34 Dec 11 14:22 /dev/tty34
crw–w---- 1 root tty 4, 35 Dec 11 14:22 /dev/tty35
crw–w---- 1 root tty 4, 36 Dec 11 14:22 /dev/tty36
crw–w---- 1 root tty 4, 37 Dec 11 14:22 /dev/tty37
crw–w---- 1 root tty 4, 38 Dec 11 14:22 /dev/tty38
crw–w---- 1 root tty 4, 39 Dec 11 14:22 /dev/tty39
crw–w---- 1 root tty 4, 4 Dec 11 14:22 /dev/tty4
crw–w---- 1 root tty 4, 40 Dec 11 14:22 /dev/tty40
crw–w---- 1 root tty 4, 41 Dec 11 14:22 /dev/tty41
crw–w---- 1 root tty 4, 42 Dec 11 14:22 /dev/tty42
crw–w---- 1 root tty 4, 43 Dec 11 14:22 /dev/tty43
crw–w---- 1 root tty 4, 44 Dec 11 14:22 /dev/tty44
crw–w---- 1 root tty 4, 45 Dec 11 14:22 /dev/tty45
crw–w---- 1 root tty 4, 46 Dec 11 14:22 /dev/tty46
crw–w---- 1 root tty 4, 47 Dec 11 14:22 /dev/tty47
crw–w---- 1 root tty 4, 48 Dec 11 14:22 /dev/tty48
crw–w---- 1 root tty 4, 49 Dec 11 14:22 /dev/tty49
crw–w---- 1 root tty 4, 5 Dec 11 14:22 /dev/tty5
crw–w---- 1 root tty 4, 50 Dec 11 14:22 /dev/tty50
crw–w---- 1 root tty 4, 51 Dec 11 14:22 /dev/tty51
crw–w---- 1 root tty 4, 52 Dec 11 14:22 /dev/tty52
crw–w---- 1 root tty 4, 53 Dec 11 14:22 /dev/tty53
crw–w---- 1 root tty 4, 54 Dec 11 14:22 /dev/tty54
crw–w---- 1 root tty 4, 55 Dec 11 14:22 /dev/tty55
crw–w---- 1 root tty 4, 56 Dec 11 14:22 /dev/tty56
crw–w---- 1 root tty 4, 57 Dec 11 14:22 /dev/tty57
crw–w---- 1 root tty 4, 58 Dec 11 14:22 /dev/tty58
crw–w---- 1 root tty 4, 59 Dec 11 14:22 /dev/tty59
crw–w---- 1 root tty 4, 6 Dec 11 14:22 /dev/tty6
crw–w---- 1 root tty 4, 60 Dec 11 14:22 /dev/tty60
crw–w---- 1 root tty 4, 61 Dec 11 14:22 /dev/tty61
crw–w---- 1 root tty 4, 62 Dec 11 14:22 /dev/tty62
crw–w---- 1 root tty 4, 63 Dec 11 14:22 /dev/tty63
crw–w---- 1 root tty 4, 7 Dec 11 14:22 /dev/tty7
crw–w---- 1 root tty 4, 8 Dec 11 14:22 /dev/tty8
crw–w---- 1 root tty 4, 9 Dec 11 14:22 /dev/tty9
crw-rw---- 1 root dialout 204, 64 Dec 11 14:27 /dev/ttyAMA0
crw------- 1 root root 5, 3 Dec 11 14:22 /dev/ttyprintk
crw-rw---- 1 root dialout 4, 64 Dec 11 14:22 /dev/ttyS0

10

The /dev/ttyS0 looks interesting. I haven’t seen that device since running linux on a computer with a ‘regular’ serial port.

11

/dev/ttyAMA0 and /dev/ttyS0 are suppose to be symlinked

12

They have different device numbers, also, I think the listing you provided would show a symlink, like: lrwxrwxrwx 1 root root 7 Dec 10 09:38 serial1 → ttyAMA0

13

Hi,

Has this been resolved?
My Octopus Pro showing similar symptoms not connecting to RPi anymore via USB-c.
UART connection presently works but is useless to me as I run usb to can bus bridge to connect my tool head.
Also flashing over usb-c via DFU doesn’t work anymore.

Sorry for hi-jacking this thread.

14

I ordered an oscilloscope and it’s suppose to arrive today. Plan on testing tomorrow.

15

My oscilloscope was delayed in the mail till tomorrow so I have been unable to further test my pins/signal till I get that set up. I did find this website that seems to indicate the Octopus pro can be on CanBus and UART2 at the same time if that helps your situation. I am afraid mine is Hardware related due to the failed C port and now UART2 demonstrating the same issues. I have a backup Octopus pro but I am contemplating buying Manta M8P + CB1 to free up the Raspberry Pi 4 for other printers.

16

Hi,
This guide is well known to me but is not 100% correct; RPi can’t communicate via UART with the Octopus while the Octopus is working as Can bridge, unfortunately not.

I have received and installed a Manta M8P with a CM4 as I need my RPi4 for other projects.
Extended the Manta with a CAN transceiver board to be able to connect my SB2040 toolhead board via Canbus; works like a charm.

Interesting though; I had to dial down accelerations quite a bit to avoid skipping coming from the Octopus Pro. Seems that there is definitely a speed difference between the boards.

I also have another Octopus Pro on the way with H723 chip (I think that is what it’s called) and I am in contact with BTT because of the USB-C failure of my Pro.

We will see.

17

After much testing with Oscilloscope found UART2 Tx pin to be not sending signal on the octopus pro. I retried USB C and it started working again. Not sure what to think about the quality of this Octopus Pro board. At this time I believe my issues are coming from faulty traces in the actual board. I did further testing before resorting back the the USB C by removing all the stepper drivers and rebooting trying to see if the UART for the steppers might be causing interference (I read that some where) but no joy was found.

1 Like
18

Hi ajscheid,
I’m also trying to setup a Manta M8P with CB1, but i’m getting the following error:

biqu@BTT-CB1:~/klipper$ ls /dev/serial/by-id/
ls: cannot access '/dev/serial/by-id/': No such file or directory

Did you encounter this issue as well? I know you’re using the CM4 in lieu of the CB1, but this seems like a communication issue between the M8P and the CB1.

19

Hi,
Sorry, saw your message only now.
Have you activated the usb ports; they are deactivated by default. Check the M8P manual; it’s described in there.

20

Hi, it just happend that somebody moved printer and USBC port unsoldered from the board. does anybody succeded with USBA?