# \[Canbus\] Debugging MCU lockups **URL:** \ **Category:** General Discussion\ **Created:** [June 9, 2024, 10:28am UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935 "2024-06-09T10:28:13Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Viesturz](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/viesturz/32/4604_2.png) [@Viesturz](https://klipper.discourse.group/u/Viesturz)\ **Post date:** [June 9, 2024, 10:28am UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/1 "2024-06-09T10:28:13Z")
Hi, I have a toolhead [MCU lockup issue](https://klipper.discourse.group/t/toolhead-mcu-timeout-errors/16719/3) that I resolved to a Usb2Can adapter glitching under high temps. I’m suspecting that it’s caused by garbled data received by the MCU and subsequently crashing. A reset of just that MCU brings it back on the bus and this occurs evenly accross 6 toolheads so fairly certain it’s a software issue. Any recommendations how to debug this? The klippy log is not helpful at all. Perhaps another canbus node, logging all the traffic? ---
**Author:** ![TheFuzzyGiggler](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/thefuzzygiggler/32/12313_2.png) [@TheFuzzyGiggler](https://klipper.discourse.group/u/TheFuzzyGiggler)\ **Post date:** [June 9, 2024, 11:43am UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/2 "2024-06-09T11:43:43Z")
[https://www.klipper3d.org/CANBUS\_Troubleshooting.html](https://www.klipper3d.org/CANBUS_Troubleshooting.html) A logic analyzer would probably be the easiest way to see if the data is garbled. ---
**Author:** ![NAPCAL](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/napcal/32/1794_2.png) [@NAPCAL](https://klipper.discourse.group/u/NAPCAL)\ **Post date:** [June 9, 2024, 12:19pm UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/3 "2024-06-09T12:19:43Z")
> [@Viesturz](#): > > Usb2Can adapter glitching under high temps If it is truly a temperature issue, move this adaptor outside of the area where it is getting hot or add a heatsink to the microprocessor and a cooling fan to blow over the board. ---
**Author:** ![Viesturz](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/viesturz/32/4604_2.png) [@Viesturz](https://klipper.discourse.group/u/Viesturz)\ **Post date:** [June 9, 2024, 4:52pm UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/4 "2024-06-09T16:52:41Z")
Thanks for the link, picking up a logic analyzer. Just to clarify, I have resolved the immediate issue by replacing the U2C adapter and adding cooling for good measure. Now looking to see if I can make the code more robust, MCUs should not be locking up from scrambled signal. Another idea could be fuzzing the canbus code. Unfortunately the MCU code has no tests to speak of. Edit: One more data point, seeing this on both RPI2040 and STM32 based toolboards. ---
**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\ **Post date:** [June 9, 2024, 5:10pm UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/5 "2024-06-09T17:10:32Z")
> [@Viesturz](#): > > MCUs should not be locking up from scrambled signal. Since quite everything in Klipper is timing sensitive or rather timing critical, why should an MCU not lock up if it no longer receives properly timed messages? FWIW and without being the authority for its deeper meaning, if you look at the log posted in the above linked thread, you will see that the RTO (Retransmit Timeout) starts dramatically rising for the ET0 MCU around 4 seconds before it crashes. ---
**Author:** ![hcet14](https://avatars.discourse-cdn.com/v4/letter/h/ecd19e/32.png) [@hcet14](https://klipper.discourse.group/u/hcet14)\ **Post date:** [June 9, 2024, 5:22pm UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/6 "2024-06-09T17:22:48Z")
> [@Viesturz](#): > > Usb2Can adapter glitching under high temps Do you use a heated chamber? There was a short discussion regarding high temps when using STM32 based CAN IFs [No Klipper problem: Maximum CAN bus toolheads temperatures regarding heated chambers Question? Poll?](https://klipper.discourse.group/t/no-klipper-problem-maximum-can-bus-toolheads-temperatures-regarding-heated-chambers-question-poll/9940) ---
**Author:** ![NAPCAL](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/napcal/32/1794_2.png) [@NAPCAL](https://klipper.discourse.group/u/NAPCAL)\ **Post date:** [June 9, 2024, 10:30pm UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/7 "2024-06-09T22:30:37Z")
CAN bus node will shutdown after reaching an error limit, this is not Klipper but how the CAN bus hardware works. ---
**Author:** ![Viesturz](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/viesturz/32/4604_2.png) [@Viesturz](https://klipper.discourse.group/u/Viesturz)\ **Post date:** [June 10, 2024, 5:58am UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/8 "2024-06-10T05:58:16Z")
Thanks Napcal, that’s good to know. Is that implemented in software in Klipper? I do not think there is dedicated canbus hardware on toolhead boards. Would it make sense for the tool board to send a shutdown message in a loop to Klipper? Klipper aborts on timeout anyway and this would help debugging. ---
**Author:** ![NAPCAL](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/napcal/32/1794_2.png) [@NAPCAL](https://klipper.discourse.group/u/NAPCAL)\ **Post date:** [June 10, 2024, 7:56am UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/9 "2024-06-10T07:56:02Z")
It is controlled by the CAN bus transceivers via the CAN bus protocol and not by the software. > **[CAN Bus Errors Explained - A Simple Intro \[2023\]](https://www.csselectronics.com/pages/can-bus-errors-intro-tutorial#can-node-states)** > > In this tutorial to CAN bus errors you'll learn about error handling, error frames, error types, states and counters - plus practical CAN bus diagnostics examples! ---
**Author:** ![Viesturz](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/viesturz/32/4604_2.png) [@Viesturz](https://klipper.discourse.group/u/Viesturz)\ **Post date:** [June 10, 2024, 9:26am UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/10 "2024-06-10T09:26:01Z")
Hmm, at least for rpi2040 it seems to be implemented by PIO. Or am I missing something? [https://github.com/Klipper3d/klipper/blob/49c0ad6369670da574f550aa878ce9f6e1899e74/lib/can2040/can2040.c#L551](https://github.com/Klipper3d/klipper/blob/49c0ad6369670da574f550aa878ce9f6e1899e74/lib/can2040/can2040.c#L551) ---
**Author:** ![TheFuzzyGiggler](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/thefuzzygiggler/32/12313_2.png) [@TheFuzzyGiggler](https://klipper.discourse.group/u/TheFuzzyGiggler)\ **Post date:** [June 10, 2024, 12:15pm UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/11 "2024-06-10T12:15:44Z")
> [@Viesturz](#): > > I do not think there is dedicated canbus hardware on toolhead boards. Every toolhead board has a CAN bus transciever, it’s required by the standard. Most boards use a: > **[sn65hvd1050.pdf](https://www.ti.com/lit/ds/symlink/sn65hvd1050.pdf?ts=1717967161942&ref_url=https%253A%252F%252Fwww.google.com%252F)** > > 908.57 KB Including the EBB 42/36 > **[BIGTREETECH%20EBB36%20CAN%20V1.1-SCH.pdf](https://github.com/bigtreetech/EBB/blob/master/EBB%20CAN%20V1.1%20(STM32G0B1)/EBB36%20CAN%20V1.1/Hardware/BIGTREETECH%20EBB36%20CAN%20V1.1-SCH.pdf)** Caveat: There are some BTT mainboards that try to get away with using the CAN H/CAN L signals over USB but that is NOT CAN bus by any definition, despite what they try to call it. > [@Viesturz](#): > > Hmm, at least for rpi2040 it seems to be implemented by PIO. Or am I missing something? The RX/TX of the actual communication is handled on the mcu, but it goes through a CAN transciever before it gets to the wiring. ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/3/330c99eba06f7aaa477cdb3f25dc24118c12b4f3.jpeg) ---
**Author:** ![mykepredko](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/mykepredko/32/2085_2.png) [@mykepredko](https://klipper.discourse.group/u/mykepredko)\ **Post date:** [June 10, 2024, 2:20pm UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/12 "2024-06-10T14:20:02Z")
> [@TheFuzzyGiggler](#): > > > [@Viesturz](#): > > > > I do not think there is dedicated canbus hardware on toolhead boards. > > Every toolhead board has a CAN bus transciever, it’s required by the standard. You think there’s a “standard”? I’ve worked with a number of toolhead boards - the first one was simply a passive plug board for my Voron. Since then I’ve bought intelligent toolhead controllers from at least three different manufacturers (I thought four) as well as different variants of the same boards (ie for attaching to 42mm and 36mm steppers) and there are a lot of differences in how CAN is implemented including the connectors used on both the toolhead controllers as well as main controller boards and U2C boards. This isn’t to say that they all won’t work together once they’re wired together it is just that you can’t assume that they all wire together the same way. You must have a basic understanding of how CAN works along with the ability to read a schematic. Even with that, I always use a multi-meter for testing the connections before applying power. I _wish_ there was a standard. ---
**Author:** ![NAPCAL](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/napcal/32/1794_2.png) [@NAPCAL](https://klipper.discourse.group/u/NAPCAL)\ **Post date:** [June 10, 2024, 2:25pm UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/13 "2024-06-10T14:25:45Z")
> [@TheFuzzyGiggler](#): > > Caveat: There are some BTT mainboards that try to get away with using the CAN H/CAN L signals over USB but that is NOT CAN bus by any definition, despite what they try to call it. Any UART communication TTL connection can be connected to a CAN bus transceiver as long as the software sending the data is using the CAN bus commands to communicate. It is a STM32 feature to use CAN bus communications over the same pins as the USB but a CAN bus transceiver is still required to connect to the bus. Most U2C adapters (example BTT U2C V2.1) have USB-A connections just for this type. ---
**Author:** ![TheFuzzyGiggler](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/thefuzzygiggler/32/12313_2.png) [@TheFuzzyGiggler](https://klipper.discourse.group/u/TheFuzzyGiggler)\ **Post date:** [June 10, 2024, 5:50pm UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/14 "2024-06-10T17:50:05Z")
> [@mykepredko](#): > > You think there’s a “standard”? I meant the ISO 11898 CAN bus standard, there has to be some sort of transceiver implementation to handle the requirements of the CAN bus. Be it integrated into an mcu (never actually seen that) or, more commonly, external. @NAPCAL > [@NAPCAL](#): > > Any UART communication TTL connection can be connected to a CAN bus transceiver as long as the software sending the data is using the CAN bus commands to communicate. > > It is a STM32 feature to use CAN bus communications over the same pins as the USB but a CAN bus transceiver is still required to connect to the bus. > > Most U2C adapters (example BTT U2C V2.1) have USB-A connections just for this type. That’s my point, the USB-A implementation isn’t CAN bus. It’s just a glorified UART at that point. It’s not differentially signaled, the characteristic impedance is wrong and there is no dominant/recessive bits that way which defines CAN communication. In other words, Can “High”/Dominant is logic “0” with the CAN H being around 3.5v and CAN L being around 1.5V. Can “Low”/Recessive is logic “1”, with both CAN H and CAN L at around 2.5V. That differential signaling gives it the noise immunity. The STM32 pins are just standard logic GPIO not a differential input. You can prove this easily because the pins can be reconfigured for other uses. ---
**Author:** ![NAPCAL](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/napcal/32/1794_2.png) [@NAPCAL](https://klipper.discourse.group/u/NAPCAL)\ **Post date:** [June 10, 2024, 6:00pm UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/15 "2024-06-10T18:00:59Z")
The CAN bus has two layers: the physical layer you are talking about and the data link layer. Yes, UART and USB are not CAN bus physical layer compatible, but that is what CAN bus transceivers are for to interface between the TTL source and the physical CAN bus. Bosh created the CAN bus protocols. Refer to their documents for the technical details you are looking for. ---
**Author:** ![TheFuzzyGiggler](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/thefuzzygiggler/32/12313_2.png) [@TheFuzzyGiggler](https://klipper.discourse.group/u/TheFuzzyGiggler)\ **Post date:** [June 10, 2024, 7:02pm UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/16 "2024-06-10T19:02:18Z")
Yes, But by ditching the physical layer you lose all noise immunity and nearly all the benefits of the CAN bus. I actually think the data layer requires error management in hardware which the STM32 doesn’t implement. But that’s a minor factor. The issue is, most users don’t understand that and when they have issues they blame CAN as a whole or Klipper. When in reality it’s just BTT cutting corners and making weird design choices by implementing something in a way it was never intended to be implemented. I’d be fine if BTT labeled it as something else, it’s less confusing that way. Or hell, Just use UART and simplify the entire thing. Even STMs presentation on bxCAN (the implementation in the low cost mcus) shows it needs a transceiver. ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/c/cd713d879a0ab8b6437c7e0a61854b7315983b13.jpeg) ---
**Author:** ![NAPCAL](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/napcal/32/1794_2.png) [@NAPCAL](https://klipper.discourse.group/u/NAPCAL)\ **Post date:** [June 10, 2024, 7:12pm UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/17 "2024-06-10T19:12:46Z")
First and foremost, most 3D print builders and manufacturers ignore the physical layer requirements for shielding the CAN bus cables. Even though the CAN bus has good noise rejection, it can still be overwhelmed by being too close to stepper wires. As well as fan and heater wires are controlled by PWM, these frequencies can cause high noise on unshielded CAN\_L and CAN\_H wires. The builder that do use shielded wiring do not typically have resending errors issues and can run at max bus speeds. ---
**Author:** ![TheFuzzyGiggler](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/thefuzzygiggler/32/12313_2.png) [@TheFuzzyGiggler](https://klipper.discourse.group/u/TheFuzzyGiggler)\ **Post date:** [June 10, 2024, 7:18pm UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/18 "2024-06-10T19:18:13Z")
Shielding is optional in ISO 11898-2, using twisted pair wiring is mandatory though. ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/5/52443ef647cda73345ef68616af6f5345c95b922.png) ---
**Author:** ![NAPCAL](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/napcal/32/1794_2.png) [@NAPCAL](https://klipper.discourse.group/u/NAPCAL)\ **Post date:** [June 10, 2024, 7:20pm UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/19 "2024-06-10T19:20:43Z")
As I said, the ones that use shielded cables have fewer issues than those that don’t. The specs were written for industrial and automotive designs, not hobbyist. ---
**Author:** ![Viesturz](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/viesturz/32/4604_2.png) [@Viesturz](https://klipper.discourse.group/u/Viesturz)\ **Post date:** [June 10, 2024, 7:37pm UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/20 "2024-06-10T19:37:12Z")
Wow, this went south fast. The canbus transcievers are just dumb differential to ttl signal level convertors, right? The protocol itself, including error handling is still in software? [Next page](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935.md?page=2)