MCU 'sb2209' shutdown: Missed scheduling of next digital out event

General Discussion
1

Basic Information:

Printer Model: Voron Switchwire
MCU / Printerboard: SKR v1.4
klippy.log

Hi everyone,

My Voron Switchwire keeps shutting down mid-print, giving me the same error: MCU ‘sb2209’ shutdown: Missed scheduling of next digital out event. The MCU thats shutting down is a SB2209 by Bigtreetech. It’s wired to a U2C, also by BTT, that I flashed with new firmware (multiple times), and thats plugged in to a RPI 3B. Then I’m using an SKR v1.4 as my main mcu, also plugged in the pi.

Everything is running the latest klipper firmware, and the SB2209 is using CanBoot. I’ve checked the bytes_invalid counter in the log, which doesn’t seem to go up during printing. The rest of the machine works perfectly, I can heat, home, and even complete small calibration prints. It just seems to shut down in the first half of any prints over an hour and I can’t figure out why. Once it shuts down, I cant reconnect to the sb2209 unless I do a full reboot of the pi. Then everything works fine again.

In this discourse I noticed a similar problem was fixed by using another RPi. As I’m also using a 3B model, I might try switching it out for something else.

The log is of a print that failed an hour in last night.
klippy (3).zip (917.7 KB)

2

Your log contain only information that printing was stalled and nothing is happening, probably issue did happened before log was rotated - before midnight by system time.

Pick previous log, archive it with Zip and send it, this log is useless.

3

Alright, sorry about that. This one was created at 23:59, found in “logs” under config files in mainsail’s machine tab.
klippy.log.zip (517.1 KB)

Thanks for your fast response!

4

Your log indicate that your CanBus have constant increase of “bytes_invalid” during print, read about it here:
https://www.klipper3d.org/CANBUS_Troubleshooting.html#check-for-incrementing-bytes_invalid-counter

That’s first issue which should be resolved.
Probably if you will fix it - you will don’t have issue anymore.

5

Just noticed the 120ohm jumper somehow fell off the U2C. This was most likely the problem, though I’m still noticing some strange behaviour.
When using python3 flash_can.py -i can0 -q for instance, no nodes are found, even though klipper connects just fine.
Any way I can verify the bytes_invalid counter is rising when not printing?

6

Well, when you are not printing - it have little communication happening with MCU, so it will not be so obvious…

Just use printer next time, after finished pring go to klippy.log and look at latest Stats and check bytes_invalid, but be sure that you are looking at correct one, your Stats contain 2 instances of bytes_invalid, one per each MCU.

7

CAN bus is very picky regarding its termination. Klipper can of course connect fine, but the CAN bus doesn’t work properly caused by wrong termination. Therefore, no nodes are found.

8

Ah, so it has to be my wiring then…
I’ve also noticed the sb2209 shows up just fine after flashing Katapult, but seems to disconnect after flashing klipper on top of that. It might even show up once as a klipper device, but I reboot and then it doesn’t show up again.

Since everything does seem to be connected, anything I should be looking for (things like resistance, wire length, etc.)?
I’m using the stock cable provided with the SB2209, connected to the U2C using the largest white molex connector. The wire is a little long tho, I’ve got it coiled up underneath the printer with the rest of the electronics. Could that be the issue?

Thanks again for the replies guys! Really appreciate y’all taking the time .

9

Did you put it back? Does the jumper sits real tight?

You could measure the termination. Two nodes → 2x 120 Ohms in parallel connection → you should measure very close to 60 Ohms with a DMM.

10

Yes, just soldered the pins together and checked with multimeter, dont want that falling off again.

Should I measure the cable between the U2C and SB2209, or between the can_h and can_l pins on each board?

I’m now following another guide on Katapult hoping I missed something during install. I’ve just flashed katapult.bin to the U2C over usb, and now it’s working fine:

basil@switchwire:~/katapult/scripts $ python3 flashtool.py -i can0 -q
Resetting all bootloader node IDs...
Checking for Katapult nodes...
Detected UUID: acb4b0e0b7a4, Application: Katapult
Query Complete

Then I flashed Klipper using:

python3 flashtool.py -i can0 -f ~/klipper/out/klipper.bin -u acb4b0e0b7a4

Which does show up/nodes are found:

basil@switchwire:~/katapult/scripts $ python3 flashtool.py -i can0 -q
Resetting all bootloader node IDs...
Checking for Katapult nodes...
Detected UUID: acb4b0e0b7a4, Application: Klipper
Query Complete

Only after rebooting the pi it stops showing up again:

basil@switchwire:~/katapult/scripts $ python3 flashtool.py -i can0 -q
Resetting all bootloader node IDs...
Checking for Katapult nodes...
Query Complete

So I’m wondering if wiring is really at fault. Maybe something gets messed up when shutting down?

11

Once Klipper accesses the UUID, it’s no longer visible via query. That’s normal. Try stopping the Klipper service and then check for nodes again.

12

I would measure with a connected CAN cable and a shut off printer on both sides, i.e. U2C and SB2209. On U2C side measure at the transceiver U5 between pin 6 (CANL) and pin 7 (CANH). On SB2209 side measure at transceiver U11 between pin 6 (CANL) and pin 7 (CANH).

1 Like
13

So today I was able to complete 2 prints without any shutdowns. I disconnected my webcam, and everything seems reliable.
I’m still noticing the bytes_invalid counter rising during printing, so I don’t think I actually fixed anything.
klippy (6).zip (1.1 MB)

Ah, that makes sense. Though it still won’t find anything when running sudo service klipper stop before checking with flashtool…

I’ll try this later tonight. Both points should measure 60 ohms, right?

14

yes.


This is really stupid.
"Post must be at least 10 characters"
15

Did you checked that your U2C have latest firmware ?

16

Alright so I got a chance to check the resistance on both boards. Thanks again for the replies everyone, much appreciated.

I didn’t entirely understand where to actually measure on the board, so I just checked the connectors where the cable plugs in… Turned off the printer and disconnected the usb from the U2C, and both sides did measure 60 ohms.
For absolute clarity: I checked the resistance on the large white molex port on the U2C, between can_l and can_h, reading 60ohms. And checked the can_l and can_h resistance on the black port of the sb2209, where the stock cable was plugged in. Also 60 ohms.

Yes, I’ve reflashed the U2C multiple times with multiple versions of candlelight.
It’s currently running THIS firmware, but I’ve also tried btt’s own firmware from their github, which didn’t connect at all. I then reflashed back to the linked firmware.
Any way I can check if it’s actually running the firmware I flashed?

And this can’t cause any problems?

17

Unfortunately I didn’t found how that can be done.
About cable length - i don’t see there problems because CanBus by specification can work up to 40m at 1Mbit speed, you still can try to striating it just for testing.

So if you U2C is updated, next possible cause declared in documentation is Linux Kernel version which you have in Rpi 3B, you can check which version do you have with command uname -a
to change it - I see few options:

  • upgrade it to latest
  • downgrade to some previous version
  • Fully update your base image and reinstall everything again
18

Thanks!
Runningg uname -a results in: Linux switchwire 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux.
So I’m running 64 bit? Should I try a 32bit version?

19

You can try to go in 32Bit, also you can try to go to latest 6.6

As main developer state in this post - it’s very hard to track it down.
In same time take a note

It is important to note that “bytes_invalid” is not the result of:

  • not related to canbus wiring
  • not related to terminating resistors
  • not related to configured canbus speed
  • not related to txqueuelen
20

I installed a 32-bit version of mainsail using pi imager and moved all the configs over, reinstalled plugens, etc etc.

uname -a

now results in

Linux switchwire 6.1.21-v7+ #1642 SMP Mon Apr  3 17:20:52 BST 2023 armv7l GNU/Linux

Still not 6.6… How would I go about updating?

I’ll try printing again tomorrow!