BTT Octopus Pro 429 + TMC5160 Drivers not communicating

General Discussion
1

Basic Information:

Printer Model: RatRig V-Core 3.1 500mm3
MCU / Printerboard: BTT Octopus Pro 429
klipper version: v0.10.0-546-a709ba43
klippy.log (131.1 KB)

Describe your issue:

I am not able to get reliable communication with my TMC5160 drivers on my Octopus Pro 429. I have both Pro and non, no combination of them changes anything and I have tried them all with only one installed. I have the CS pin of the MAX31865 held high with a static output pin. I have dropped down to 1MHz on the bus for testing.

Most of the time the printer shuts down with the infamous Unable to write tmc spi 'stepper_?' register GLOBALSCALER but on a rare occasion (no pattern I can discern) it will work. Based on my last few logs the actual issue is that a driver will respond with TMC 'stepper_?' reports DRV_STATUS: ffffffff which is clearly a bad transmission of some kind and causes klipper to request an emergency stop.

I have been at this for over a week and I think I’ve gotten to the root problem, but I’m going to need some help @koconnor (sorry for the direct tag, but I have a feeling this issue is deep within the mcu code and I have a feeling you’re probably the only one familiar enough with the code to find it).

The MISO line for the spi1 bus is running at 5V for everything except the mcu, the blow snippet of the schematic shows the level shifter circuitry. MISO goes to all 8 driver sockets, the MAX31865, and the EXP2 header. SPI1_MISO goes to the mcu.

schematic

I have been probing the bus over a few days now but I’ve been doing it from one of the driver sockets. Nice square waves and nothing that looks out of place on SCLK, MOSI, or MISO. But today I probed the MISO line on both sides of the level shifter for the first time and I think I’ve found the issue (symptom not cause). More details below, but here is a snippet where you can clearly see that the mcu side of the circuit is being held high (my guess is the pin gets switch to output and set high) and then klipper reads all 1s and gets the aforementioned ffffffff from the driver.

scope results

From the moment I hit Home All to the moment klipper shuts down there are 25 transactions that happened on the bus this time. Most of them are the same 2 packets (I’m calling a 40-bit exchange a packet here) which seem to be klipper periodically reading back the status of the driver. On the 18th transaction only the first packet gets through, the second packet in the transaction gets read as ffffffff because the mcu line gets pulled high (see above image). The SPI1_MISO line remains high after that point and then klipper descides that something is wrong and shuts down. It seems to me that the first time klipper reads ffffffff it doesn’t shut down, because it keeps running the spi bus for 6 more transactions after that, so I don’t think klipper shutting down is the cause of the SPI1_MISO pin being set high.

Full Session (130.3 KB)
PulseView win64 needed to open it

Unfortunately I only have a 2 channel scope so I wasn’t able to capture the SCLK and MOSI signals to be able to view the whole transaction and decode. If it would help to know what actual data is getting sent by the drivers I can go through the above session and decode manually for you.

I have plenty of personal experience with electronics, microcontrollers, coding, etc. Happy to dig through datasheets if you have a hunch and do all manner of testing.

Thank you for the help!

2

As a test to see if the buffers are causing the problem.

  1. Pull the driver jumpers for the SPI CLK, MISO, and MOSI for all of the drivers, and leave the CS jumpers in place.
  2. Install jumper wires from the SPI3 connector to the drivers using SPI control.
  3. Change the SPI assignment in the printer.cfg

This helped one owner that a driver damaged the buffer for the driver SPI signals.

3

There are also reports that other SPI devices, e.g. displays, MAXxxxxx etc, are causing troubles when on the same SPI bus.
I’d try to simplify the setup to the bare minimum and work from there.

4

I had suspected that near the beginning of this journey, and found the documentation on it that confirmed it. I did mention I have disabled my MAX31865 as I am not using it.

I have as much as I know how to. I’ve dropped down to a single driver and tried every one I have (2x Pro, 5x standard). I’ve also tried 4MHz, 2MHz, 1MHz, 100kHz with no luck.

5

Thank you for this!

I have a Pro driver that I suspect has a short (heats up a lot at idle) but while scoping the bus I see good communcations still so I figured it hadn’t done any damage.

I’m going to put the suspected bad one back on the board and check the bus again, it’s the only one I haven’t put on the scope.

6

If I understood well, @NAPCAL suggested to try SPI3 instead of SPI1 by manually routing the driver pins via jumper cable. This should help determining if the SPI1 bus has gone bad because of a faulty driver. Of course you should not try this with a suspected / known bad one.

7

Yeah lol, I’m not going to shoot my other foot as well haha. Going to try this now, will report back in a bit.

8

Yes, SPI3 has a direct connection to the ARM STM32 unlike the protection buffers on SPI1.

Until you know the good drivers don’t hook them to SPI3.

Check for ground and supply shorts on the drivers off the board first.

9

Yes, I just looked at the schematic and saw that. I have some BSS138 level shifter boards handy so I will use one of those. Not sure how fast they are so I’m going to run at 100kHz to start.

10

@NAPCAL I could kiss you right now! A week of bashing my head against this problem and beginning to lose hope and now it lives! Sometimes a solution is too obvious to see.

I ended up using some 74HC125 buffer chips I had instead of the BSS138’s because they are much faster. It’s messy but I’ve got it rigged up now so I can at least run my printer until BTT gets back to me about warranty.

@Sineos thanks for your quick responses. I don’t think I’ve seen anyone so active on a forum before, your work is appreciated sir!

1 Like
11

Didn’t find any that didn’t belong (I think?). All 7 drivers show a 150k ohm short between VCC-IO and GND but that’s it.

Is it normal for the drivers to get warm with the motors disabled? My “bad” Pro driver gets almost too hot to touch if left on for several minutes, but the other one becomes warm. None of my standard ones do this, they stay cool to the touch until they are enabled.

12

I will not be in front of mine until this weekend to check resistance and temperature.

13

@crazyivan359, where did you end up with this? I ran into the exact same issue - perfectly good SPI comms with the step stick before the level shifter (checked with a 4ch oscilloscope), but a stuck high MISO line after. Did you get the board replaced? Any issues with that? Have you tried replacing the diode after the level shifter, and/or the level shifter?

14

@correctalex I have not tried replacing anything on the board, nor will I with this one as its a warranty issue as far as I’m concerned. That said I have yet to get a response from BTT about the Octopus or dead driver.

I am still running off of SPI3 using 74HC125 on a breadboard. It’s janky but at least I can use my printer.

I didn’t even check the diode, but now I’m curious. I’ll have to think to check that this weekend because if that’s all it is I might try to change it if I still can’t get a response from BTT.

15

I’ve gone a bit further now - I’ve removed the pull-up (after the level shifter) and diode, to be able to probe the signal after the level shifter independently. That still looks healthy, so it’s not the level shifter. The diode itself is also fine, but for good measure I tried with just a series resistor instead (to limit the current if the MCU pin is accidentally configured as an output). Same result, though - the signal at the MCU pin is stuck high. Seems to me that the MCU pin itself is dead in my case.

I’ve now soldered on a hook-up wire from after the level shifter (with the diode still removed) so I can connect the MISO signal to some other pin and just try with software SPI. I haven’t had a chance to test that yet, though - hopefully later today.

I’ve also sent BIQU/BTT an email for support - we’ll see if I have better luck.

16

Yeah you got into it a bit more than I did, I skipped right to using SPI3.

Hopefully you have more luck than I, it’s been over a month now and I’m still waiting

17

Hello, i try the same since my SPI1 is not working. When i change the config it says: PB4 / PB5 / PB3 is reserved for SPI3. so Printer runs in fault.

Its a Ratrig with AWD mod.