@MLoewe well that’s basicaly what i’ve done. Just without CanBoot. Can2USB bridge on SKIPR seems to work, but i cannot see the Toolhead bord on the CanBus, only the bridge.
For what it is worth, I don’t have any hands on knowledge of the MKS board, so there isn’t much information I can provide.
If you have a separate USB-to-CAN adapter you could try using that for diagnostic purposes. For example, try hooking up the sb2040 via canbus to that adapter and verify that query_canbus.py identifies the device. That will confirm the sb2040 firmware configuration. You could also try hooking up the usb-to-can adapter to the SKIPR board to see if it can see messages being generated by the SKIPR board. Linux has some tools for sending and reading canbus packets - install it with sudo apt-get install can-utils, and then one can run cansend and candump. When I debug these devices, I tend to open a terminal window and run candump -t z -Ddex can0,#FFFFFFFF to see all the low-level packets on the device. These tools also work when Klipper is in “USB to CAN bridge mode”. With some troubleshooting, it should be possible to identify if the issue is with the SKIPR or SB2040 boards.
-Kevin
2 Likes
Thanks Kevin for your reply.
I have the EBB36 from BTT and with the U2C adaptor on the SKIPR i can see the toolhead.
Only when i connect it directly to the SKIPR, i can’t see the EBB36 (yes, i changed the pinout of my canbus cable ^^)
By the way, will/is it possible to access the canbus via uart? So we don’t need an additional usb c cable from the rockchip to the stm32?
i think it is mx3.0 mm 2x2
So I got my UTOC Adapter now, working as expected with SB2040 in CAN mode. But still no luck getting SKIPR to work with Bridge mode… That still sux.
1 Like
Yep, external solutions should be no problem at all.
I can live with an additional usb cable from the rockchip to the stm32 to use it in brdige mode, but using it via the common uart would be nicer too.
I’ve got my SKIPR + Mellow fly SHT42 now and I have strange issues with CAN.
If I try to configure CAN in a same way as @opiswahn described above it works unreliable.
The CAN0 interface connects coincidentally only. Sometimes it is configured, the next bootup it is not.
I’ve given up now and will connect the toolhead MCU via USB.
Some questions:
-
Has anyone done a system upgrade for armbian? MKS does not recommend doing an upgrade because of “transplanted system files”
I did the upgrade anyway and everything seems to be working fine in USART mode -
Do you use SD cards or EMMC modules for the Armbian system? I fear that it doesn’t work well with SD card. The system stucks occasionally, although no process is using CPU load.
-
Does anyone knows the difference between “mcu” and “mcu rpi” in printer.cfg? MCU is clearly the STM32 connected via USART. But what the hell is “mcu rpi”?
[mcu]
serial: /dev/ttyS0
restart_method: command
[mcu rpi]
serial: /tmp/klipper_host_mcu
I suppose we just need an (USART to CAN bus bridge (USART on PA9/PA10)) option in the klipper “make menuconfig”. But I’m not sure if that’s easily interchangeable with the existing (USB to CAN bus bridge (USB on PA11/PA12)) option. One could adapt the Kconfig/sourcecode accordingly to try it out 
1 Like
-
I’ve tried updating kernel and all, ended in total desater
, so i’m using the provided (pretty outdated) image from MKS. At least apt-get update/upgrade works, no issues with that. -
I’m using the SD-Card. Works flawless so far, at least i cannot see any difference to an RPi with an SD card, behaves quiet the same performance wise as far as i can tell.
-
The MCU is the STM-Part of the SKIPR. Connected via serial to the onboard MKS-PI. The [mcu rpi] is the linux hosting process used for InputShaping. For details see here.
As for the Toolhead board, I somehow fried my sb2040, so I replaced it with the Fysetc CAN TH board. This one has a STM F0 chip, not the raspberry 2040. Works way better(at least for me), way more stable and quicker to initialize.
You have to enable hotplug / autovonfig in your network.conf for the can interface
-
ok, I did apt update/upgrade only. With your information, I will thankfully forgo the kernel update.
-
Hmmm… my SD Card is old. Maybe I should try a new one. Anyway, I also ordered an 32G Emmc module. At the moment my MKS-Pi is significantly slower then my Raspi Pi 3
He is often stuck. Installing klipper via Kiauh takes almost an hour or so… -
Ahhh… ok. Thx!
I have hotplug and autoconfig enabled in:
/etc/network/interfaces.d/can0
Is that what you mean?
try the armbian-config tool. There you can configure the min and max speed of your cpu, also the CPU-governor mode. Try setting ‘performance’, but beware, it will always run at max speed, wich may result in high cpu temp. I’m using ‘ondemand’
2 Likes
The armbian governor setup is correct. That’s not the reason why the system stucks.
Can you pls check the kernel messages (dmesg) on your mkspi? I have a strange output regarding to IRQ57:
[ 99.411035] irq 57: nobody cared (try booting with the "irqpoll" option)
[ 99.411056] CPU: 0 PID: 69 Comm: irq/57-rk805 Tainted: G C 5.16.20-rockchip64 #trunk
[ 99.411066] Hardware name: Makerbase mks-pi (DT)
[ 99.411071] Call trace:
[ 99.411074] dump_backtrace+0x0/0x200
[ 99.411089] show_stack+0x18/0x28
[ 99.411097] dump_stack_lvl+0x68/0x84
[ 99.411105] dump_stack+0x18/0x34
[ 99.411111] __report_bad_irq+0x4c/0xdc
[ 99.411120] note_interrupt+0x174/0x3c8
[ 99.411128] handle_irq_event_percpu+0x84/0x90
[ 99.411137] handle_irq_event+0x48/0xe8
[ 99.411145] handle_level_irq+0xd0/0x160
[ 99.411152] generic_handle_irq+0x30/0x48
[ 99.411160] rockchip_irq_demux+0xd8/0x258
[ 99.411168] generic_handle_domain_irq+0x3c/0x60
[ 99.411176] gic_handle_irq+0x98/0xc8
[ 99.411186] call_on_irq_stack+0x28/0x50
[ 99.411193] do_interrupt_handler+0xd8/0xf0
[ 99.411201] el1_interrupt+0x38/0x88
[ 99.411210] el1h_64_irq_handler+0x18/0x28
[ 99.411216] el1h_64_irq+0x74/0x78
[ 99.411222] _raw_spin_unlock_irq+0x1c/0x48
[ 99.411230] irq_finalize_oneshot.part.56+0x68/0x108
[ 99.411239] irq_thread_fn+0x60/0xa0
[ 99.411248] irq_thread+0x138/0x238
[ 99.411256] kthread+0x15c/0x170
[ 99.411264] ret_from_fork+0x10/0x20
[ 99.411271] handlers:
[ 99.411273] [<000000002279ffdc>] irq_default_primary_handler threaded [<00000000f9dd71ae>] regmap_irq_thread
[ 99.411295] Disabling IRQ #57
Is that normal???
IRQ 57 belongs to the rockchip rk805, this is a power supply related chip.
57: 200001 0 0 0 rockchip_gpio_irq 24 Level rk805
Thanks in advance!
Ralf
I suppose we just need an (USART to CAN bus bridge (USART on PA9/PA10)) option in the klipper “make menuconfig”. But I’m not sure if that’s easily interchangeable with the existing (USB to CAN bus bridge (USB on PA11/PA12)) option. One could adapt the Kconfig/sourcecode accordingly to try it out
Simply adding the option in kconfig won’t work. Simultaneous USB and CAN communication is a hardware feature on certain STM chips. I don’t believe simultaneous UART and CAN is supported by the hardware.
1 Like
Okay, today I’ve given the CAN bus connection a second chance.
Here’s what I’ve noticed:
- The CAN connection between the CPU and the MCU part of the Skipr board with an additional USB cable now also works for me
- However, the hot plug does not work reliably. When I disconnect and reconnect the USB cable, the connection is not automatically renewed
- When I connect the Mellow SHT36 (with CAN firmware) it is not displayed under Linux (same issue as described above).
- In addition, the connection between CPU and MCU is interrupted when I connect the SHT36
Klipper loses contact after a few seconds and the CAN-uuid of the MCU is no longer displayed by the Python script. This can only be repaired if I disconnect the SKIPR board from the power supply. A reset or reboot is not enough (no hotplug!).
I am sure that I have correctly compiled the firmware and the settings under Linux are also correct.
Under these conditions, the CAN-connection between MKS-Pi and the MCU is IMHO useless. With USART, you can at least do it without the additional cable.
This is all very frustrating and unsatisfactory. I actually bought the SKIPR because of the possibility of the CAN bus connection 
Yea, me too. For now I ended up using a UTOC board as the CAN connection, at least that works flawless. Wouldn’t have needed the SKIPR for that, just could have added this to my old setup and would have saved me a ton of headache…
Ah well, maybe someday MKS will fixup the board, then I will try again.
1 Like
Sounds like you have switched wires?
Check that high and low are correctly connected and that you have on the toolhead board and the mcu the same baudrate.
No, I have not reversed the wires. I’ve checked the connection multiple times and I am absolutely sure!
To exclude the possibility of incorrect labelling of the H/L pins on the PCB, I also swapped the wires as last try. Same result…
The baud rate was of course configured the same everywhere. I tried both settings: 250000 and 500000! Same on both sides…
I compared the Octopus and the Skipr schematics too. It seems that the can bus implementation is identical on both platforms. Strange that it is not functional on the Skipr board 
The MCUs are different. STM32F446 on Octopus, STM32F407 on Skipr. But both MCUs have 2 × CAN interfaces (2.0B Active). So identical…
Perhaps the circuit diagram of the Skipr does not match the actual construction. Otherwise I am at a loss…
1 Like