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)
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.
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.
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.
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!