HermitCrab not communicating over canbus with klipper

[infinisean]

After some trial and error, I was finally able to get Klipper to compile and install to my BTT HermitCrab controller…

 

pi@octoPizzle2:~/klipper $ lsusb

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Bus 001 Device 007: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

Bus 001 Device 003: ID 046d:c31c Logitech, Inc. Keyboard K120

Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 

pi@octoPizzle2:~/klipper $ make flash FLASH_DEVICE=0483:df11

  Flashing out/klipper.bin to 0483:df11

sudo dfu-util -d ,0483:df11 -R -a 0 -s 0x8000000:leave -D out/klipper.bin

 

dfu-util 0.9

 

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.

Copyright 2010-2016 Tormod Volden and Stefan Schmidt

This program is Free Software and has ABSOLUTELY NO WARRANTY

Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

 

dfu-util: Invalid DFU suffix signature

dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!

Opening DFU capable USB device...

ID 0483:df11

Run-time device DFU version 011a

Claiming USB DFU Interface...

Setting Alternate Setting #0 ...

Determining device status: state = dfuERROR, status = 10

dfuERROR, clearing status

Determining device status: state = dfuIDLE, status = 0

dfuIDLE, continuing

DFU mode device DFU version 011a

Device returned transfer size 2048

DfuSe interface name: "Internal Flash  "

Downloading to address = 0x08000000, size = 21464

Download        [=========================] 100%        21464 bytes

Download done.

File downloaded successfully

Transitioning to dfuMANIFEST state

dfu-util: can't detach

Resetting USB to switch back to runtime mode

 

 and initialize properly (verified by running “dmesg | grep -i can”)

 

[    6.346440] CAN device driver interface

[    6.363660] mcp251x spi0.0 can0: MCP2515 successfully initialized.

[62184.029014] can: controller area network core

[62184.038379] can: raw protocol

 

However, when I run the "canbus_query.py" script, it executes and returns with no canbus IDs of devices found on the bus.

 

pi@octoPizzle2:~/klipper $ ~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0

Total 0 uuids found

 

The thing is, I DO see packets come back on the can0 interface, each time I run the query  

i.e. when I run the query script and then do "ifconfig can0" to check the interface packet counters, I see the TX Packets

increment by one packet and RX Packets increment by two packets for each time I run the script. 

 

root@octoPizzle2:~ # ifconfig can0

can0: flags=193<UP,RUNNING,NOARP>  mtu 16

        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 128  (UNSPEC)

        RX packets 28  bytes 209 (209.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 17  bytes 13 (13.0 B)

        TX errors 1  dropped 1 overruns 0  carrier 1  collisions 0

 

I even ran tcpdump on the can0 interface and see actual packets 'on the wire'.   

Note, I verified the packets are indeed coming back from the HermitCrab controller by running the packet capture with the HC connected and with it disconnected.   When it is disconnected I only see a single packet go out with the request but when it is connected, I see the additional return packets, as expected... yet they do not show up in the query script output

 

With the HermitCrab disconnected:

pi@octoPizzle2:~/klipper $ sudo tcpdump -i can0

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on can0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

 

20:23:36.372234

        0x0000:  f003 0000 0100 0000 0000 0000 0000 0000  ................ (this is the broadcast for other devices on the bus)

 

With the HermitCrab connected:

pi@octoPizzle2:~/klipper $ sudo tcpdump -i can0

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on can0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

 

20:23:36.372234

        0x0000:  f003 0000 0100 0000 0000 0000 0000 0000  ................

20:23:36.373107

        0x0000:  187f ef87 0800 0000 dfdf ffdf ddfc 1f1d  ................   (These are packets back from the Hermit)

20:23:36.373215

        0x0000:  f003 0000 0100 0000 0000 0000 0000 0000  ................

20:23:36.373517

        0x0000:  f903 0040 0700 0000 303f 677f f71b 7600  ...@....0?g...v. 

I have tried changing the speed from the recommended 250000 to 115200 to see if a lower speed would help and I tried both 8MHz and 12 MHz for the reference oscillations, without any improvement.  

 

So, as far as I can tell from dmesg, ifconfig, etc… the canbus driver is initializing properly, the interface comes up without error and everything looks like it is working… it just fails to ever show there is anything else on the canbus, even when there are packets coming back from another device on the canbus. 

 

It seems like the packets the HermitCrab is sending back may be corrupted but I have no way of proving that as I can’t decode the canbus traffic.

 

I am not sure where to go next, troubleshooting wise, in order to get the HermitCrab talking with my other devices on the canbus so any suggestions or assistance would be greatly appreciated.

 

Thank you in advance for your assistance!

[BTT Tony]

Hi，

Did you follow this link? At which step did you have the problem?

https://github.com/bigtreetech/HermitCrab/tree/master/CanbusKlipper/Klipper
 

[Raymond]

Have the same problem. Did you ever figure this out?

 

[BIQU info]

On 6/26/2022 at 7:14 PM, Raymond said:

Have the same problem. Did you ever figure this out?

 

If you have any product issues, please submit a request and we will arrange for an engineer to communicate with you as soon as possible.

Click on the top navigation "Submit a request" or Please click
https://support.biqu3d.com/hc/en-us/requests/new

[m-p]

I have a similar problem.

Running a BTT U2C attached via USB to a RPi running klipper.

Can0 works at the OS level - interface comes up/down on command, running tcp dump against can0 shows packets going over the interface (I disconnected the remote can device, so packets seen in tcp dump must be transmitted out can0).

But for some reason, the Klipper uuid query script shows the same "total 0 uuids found" that the OP also received.

 

@BIQU info directing people to open a case is dumb because solving in this thread is useful for other people that find it when searching for solutions. 

[BIQU info]

Hello, we need to confirm some details with you. What's the model of your motherboard? What is for your combination? Octopus+U2C+ RPI? Please send more detail to our technicians, and they will help you to solve it.

 

[m-p]

Solved my problem. Some notes.

 

- Topology is: RPI --usb-- U2C --canbus-- EBB42

- Running the uuid discovery script was resulting in no uuid found. 

- I realized that the uuid that we're looking for isn't that of rpi/can0:  rather we want to find ebb42's can0 interface uuid . (Maybe this is implied in some documentation somwhere, but it's sure not explicit)

- After realizing that we're actually trying to find ebb42/can0's uuid I widened what I was looking at to include the ebb42 and the can link to it

- Moved ebb back to usb power to try to verify fw flash was good - realized it has some leds on when powered that I didn't see in my earlier testing 

- Looked to docs to try to figure out if VBUS (that's what it's labeled on the board, though the docs all call is VUSB - I don't know which is the typo) jumper needs to be installed to power ebb from 24v 4pin connector. Docs are really bad and don't address this - I was left to guess (I guessed correctly that jumper is not required). 

- I soldered 24v power directly to the backside of board, leds lit up, uuid is discovered. This was just an "ebb has no power" issue the whole time.

- My ebb42 is v1.2 (from board stencil) which is not referenced anywhere in docs. I don't know if v1.2 if a knockoff (someone knocking off btt, oh the irony) or if docs are just out of date. Probably just a docs problem.

- BTT should really look at their EBB github repo and do some work there. It's shamefully bad right now.

Edited January 6, 2023 by m-p