Nice dude, we’ll try 
Yes mate, i think you solved the issue.
Looks promising:
mks@SKIPR:~/klipper-git/klipper$ python3 ./scripts/canbus_query.py can0
Found canbus_uuid=3fcexxxxx296, Application: Klipper
Found canbus_uuid=f8caxxxxxa55, Application: CanBoot
successfully flashed klipper over canboot.
my EBB36 seems to be full recognized.
but now with the next step, a get an error within klippy
klippy.log (25.3 KB)
printer.cfg (8.2 KB)
Seems klippy has a problem on the toolhead.
Great work Kevin!
I tried it out but have a problem while compiling the toolhead FW.
After installing your patch I compiled the new mcu FW. All seems to be fine… the CAN toolhead is found for the first time:
The toolhead has only canboot flashed so I tried to compile the Klipper FW for CAN:
mks@mkspi:~/klipper$ make clean
mks@mkspi:~/klipper$ make
Creating symbolic link out/board
Building out/autoconf.h
Compiling out/src/sched.o
Compiling out/src/command.o
Compiling out/src/basecmd.o
Compiling out/src/debugcmds.o
Compiling out/src/initial_pins.o
Compiling out/src/gpiocmds.o
Compiling out/src/stepper.o
Compiling out/src/endstop.o
Compiling out/src/trsync.o
Compiling out/src/adccmds.o
Compiling out/src/spicmds.o
Compiling out/src/thermocouple.o
Compiling out/src/i2ccmds.o
Compiling out/src/spi_software.o
Compiling out/src/sensor_adxl345.o
Compiling out/src/sensor_angle.o
Compiling out/src/sensor_mpu9250.o
Compiling out/src/lcd_st7920.o
Compiling out/src/lcd_hd44780.o
Compiling out/src/buttons.o
Compiling out/src/tmcuart.o
Compiling out/src/neopixel.o
Compiling out/src/pulse_counter.o
Compiling out/src/stm32/watchdog.o
Compiling out/src/stm32/gpio.o
Compiling out/src/stm32/clockline.o
Compiling out/src/stm32/dfu_reboot.o
Compiling out/src/generic/crc16_ccitt.o
Compiling out/src/generic/armcm_boot.o
Compiling out/src/generic/armcm_irq.o
Compiling out/src/generic/armcm_reset.o
Compiling out/src/../lib/stm32f0/system_stm32f0xx.o
Compiling out/src/generic/timer_irq.o
Compiling out/src/stm32/stm32f0_timer.o
Compiling out/src/stm32/stm32f0.o
Compiling out/src/stm32/gpioperiph.o
Compiling out/src/stm32/stm32f0_adc.o
Compiling out/src/stm32/stm32f0_i2c.o
Compiling out/src/stm32/spi.o
Compiling out/src/generic/canserial.o
Compiling out/src/../lib/fast-hash/fasthash.o
Compiling out/src/stm32/can.o
src/stm32/can.c: In function 'canhw_set_filter':
src/stm32/can.c:135:20: error: 'CAN1' undeclared (first use in this function); did you mean 'CAN'?
uint32_t fmr = CAN1->FMR;
^~~~
CAN
src/stm32/can.c:135:20: note: each undeclared identifier is reported only once for each function it appears in
src/stm32/can.c: In function 'can_init':
src/stm32/can.c:249:29: error: 'CAN1' undeclared (first use in this function); did you mean 'CAN'?
enable_pclock((uint32_t)CAN1);
^~~~
CAN
make: *** [Makefile:64: out/src/stm32/can.o] Fehler 1
The sht36 has a STM32F072 mcu. In the relevant declaration there is no CAN1 declaration indeed:
#if CONFIG_MACH_STM32F0
#define SOC_CAN CAN
#define CAN_RX0_IRQn CEC_CAN_IRQn
#define CAN_RX1_IRQn CEC_CAN_IRQn
#define CAN_TX_IRQn CEC_CAN_IRQn
#define CAN_SCE_IRQn CEC_CAN_IRQn
#define CAN_FUNCTION GPIO_FUNCTION(4) // Alternative function mapping number
#endif
Could this be the problem?
Thanks in advance!
Ralf
Yeah, it’s a bug in the quickfix.
In line 136 in can.c it’ll check for not equal CAN1.
Just use the original can.c for your toolhead.
Yes, meanwhile I had the same idea 
Do you have checked your printer.cfg related to PB13?
I suppose it is a duplicate entry 
Now I have successfully connected my Mellow Fly SHT42 toolhead to the SKIPR CAN connector!
- at the SKIPR mcu klipper is builded with your patched can.c
- at the sht42 toolhead klipper is
builded with the original can.c
It seems to be working 
I can read the thermistor values and start the fans!
Really nice!
Ralf
1 Like
Thanks. I made a change to the code at stm32: Fix CAN2 handling in can.c by KevinOConnor · Pull Request #5988 · Klipper3d/klipper · GitHub . Can you pull that latest code and retry with that code on both the f407 and f072 boards?
-Kevin
2 Likes
You’ll need to complete your config. In particular, if stepper_x is a tmc5160, then you’ll need to specify the spi bus that driver is connected to.
-Kevin
I’ve compiled and flashed your latest code on both the f407 and f072 boards now.
It compiled without warnings or errors and it seems to run perfectly on the skipr/sht42 
A big THANKS!!!
Keep it up 
Best regards from Germany
Ralf
I’ve attached my config.
With the use of my U2C USB to CAN adapter the config already worked.
I could read my driverstates and control a neopixel connected to the toolhead.
And if i look at the klippy.log, it’ll try to reserve canbus and spi on pb13 on the toolhead.
Does anyone have a chance to test with Fly SB2040? I couldn’t get it to recognize even though have checked the patched branch.
Here are the steps:
- I checked out the patched branch and compiled firmware for MCU with the below setting
Also, I plug the USB from MCU into the Pi side. Everything worked.
- I compiled firmware for SB2040 with the below setting and successfully flashed it to SB2040.
Still, only Klipper UUID is found. I have tried to plug and unplug the 120Ohm resistor on SB2040 and still, nothing worked.
I just hope that I do not make a mistake somewhere
I used to have the Fly SB2040, but I bricked it, now using the Fysetc SB TH, all working fine.
From what i can see from the PR is that the fix is exclusively for the STM based boards, but the SB2040 is different as it is a Raspberry Chip. I’d guess an additional fix is needed for those boards.
BTW @koconnor @Cosmicos I can also confirm the fix works fine on the Fysetc SB TH (which is also a F072), but that was to be expected.
1 Like
So that’s why I stop hearing from you about your SB2040. I’m sorry to hear that.
In the meantime, I guess I will keep messing around and hope for the best. I really love the design of SB2040
No, as far as I understood the patch refers to the STM MCU of the SKIPR board. The toolhead’s MCU is not affected by the patch. STM or SB2040 on the toolhead shouldn’t matter.
For example, I compiled my toolhead firmware without the patch and it works.
Try flashing the original version (without patch) onto the toolhead. That’s how it worked for me too.
Wrong, refers to all stm boards.
Klipper doesn’t differ between mainboard or toolboard.
You should only use this patch with this skipr board.
For the toolhead, use the main branch.
Yes, of course. I must have phrased that wrong.
I wanted to say that the patch doesn’t matter on the toolhead. It is only relevant for the STM-MCU board, SKIPR or not.
If I compile Klipper for the toolhead with the patch it can’t connect.
If I compile Klipper for the toolhead without the patch I’ll work!
That’s correct. This is how it works for me.
Unfortunately, this does not work for me.
I have to use UTOC then. Really want to avoid that board, but guess I have no choice.
And… Still does not work with UTOC. Maybe I did something wrong
1 Like