TLDR: @Esoterical’s guide states that “SKR Mini E3 V3 can be run in USB-CAN-Bridge mode if you use the PB8/PB9 pins on the EXP1 header” but I’m not seeing any voltage change at all on the PB9 (TX) pin when I try to run canbus_query.py.
I flashed Klipper with the below menuconfig, connected a MCP2551 breakout, and I’m able to use canbus_query.py to discover the SKR Mini E3 V3’s uuid, but I’m not able to discover anything else on my CAN network.
To rule out problems with other devices on the network, I’ve hooked my oscilloscope directly to PB8/PB9 to make sure the SKR Mini is transmitting. I’m seeing both PB8 and PB9 pulled to 3.3V (which I believe is correct for CAN GPIOs). But when I run ~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0 I don’t see any movement on the TX pin (or the RX pin for that matter). I should expect to see some sort of signal there right? I’m wondering if there’s some bug in how the CAN peripheral is initialized.
Is anyone successfully using the SKR Mini E3 V3 in CAN Bus Bridge mode?
I have personally run an SKR Mini E3V3 in usb-can-bridge mode (hence why I used it as an example).
Have you added a transceiver board to the PB8/9 pins as well?
Good to know, thanks @Esoterical and thanks for such an excellent guide!
Yes I have a transceiver board on there (based on the MCP2551 transceiver chip). But even without the transceiver board you’d expect the TX pin to pull to ground at least briefly when running canbus_query.py right?
I wonder what the simplest test is that would allow me to prove FDCAN is set up properly. Seems strange to me that I’m getting nothing out of PB9. I wonder if my FDCAN peripheral got busted somehow.
CAN FD is not supported by Klipper anyway, but it is backwards compatible.
Apart from that, just create a full printer.cfg file and run Klipper. If it connects, and you can control the board, everything is fine.
I think you’re talking about something else. FDCAN is the name of the CAN peripheral used by STM32 for CAN communication. It’s configured in src/stm32/fdcan.c.
My USB to CAN bus bridge can talk to itself but no other devices, which is not very useful for a CAN bus bridge
Thanks for the data point! It’s helpful to know it’s working for others.
Since I’m not getting any voltage change out the PB8/PB9 pins (other then getting set to 3.3V at boot) I’m wondering if I fried the CAN peripheral. I’m using a MCP2551 which I saw others had used, but reading the datasheet I see that’s a 5V adapter and the STM32 is 3.3V. If I reconfigure PB8/PB9 as GPIO I can still toggle them so the pins aren’t entirely burned, but I wonder if I could have fried the FDCAN1 peripheral. Unfortunately there aren’t any open pins that hook up to the FDCAN2 peripheral on the SKR Mini E3 V3.
Anyone have any ideas on how to prove whether or not the STM32’s CAN is functional? Hooking up an oscilloscope directly to PB8/PB9 and running ~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0 is what I’m trying but I don’t see any signal from PB9 when I do this.
I fired off a couple prints today and about 10-15 minutes into the print I got: "MCU 'mcu' shutdown: Missed scheduling of next digital out event". The SKR Mini E3 V3 was still in USB to CAN bus bridge mode, but there’s nothing else on the CAN network (I’ve temporarily given up on setting up a CAN toolhead). Looking at klippy.log shows bytes_retransmit=2563 bytes_invalid=35595 before I rebooted the printer.
I’m on v0.13.0 (61c0c8d2). To get the prints done I reverted back to normal USB (on PA11/PA12) mode (which has been working reliably for the last few months). The print finished successfully after moving back to that mode.
It’s very surprising to me that the SKR Mini E3 V3 would have trouble communicating with even itself in USB to CAN bus bridge mode. Does that suggest to any of y’all some deeper hardware issue? Does the primary MCU in USB to CAN bus bridge mode even use the CAN peripheral when the message is for itself?
