BTT Octopus Max EZ & EZ5160 SPI Issue

[pporcaro]

Basic Information:

Printer Model: Modix Big Meter
MCU / Printerboard: BTT Octopus Max EZ/STM32H723x
Host / SBC: BTT Pi 2
klippy.log: logs&cfg.zip (54.2 KB)

Describe your issue:

I’ve got a rather strange issue in attempting to set up a BigTreeTech Octopus Max EZ with EZ5160 (TMC5160 clone) drivers in my company’s Modix Big Meter.

I managed to set up the config so that I was able to get the steppers moving, and all was going great…until I made a small change to the config (unrelated to the issue - I was tweaking driver direction polarity, so the two x carriage motors move together) and then saved the config and restarted the mainboard. All of a sudden, the STM32 completely lost contact with every single driver.

After a good few hours of research, I realized these drivers from BTT have an abysmal failure rate, so I was fairly suspicious of this – but after seeing as every single driver had lost comms through SPI, I became even more confused. Running DUMP_TMC on each driver yielded the same result - no response from the EZ5160, MISO stays high at 3.3v and all registers read back FFFFFFFF as a result. See the traces from my oscilloscope below when I passed G28 into the console (note that the trigger isn’t configured correctly and the data is bit shifted right by one position as a result - it should start with the 1 in position 38):

As you can see above, after the first 40 bits, the clock goes high for ~1µs and then resumes oscillating, but there is no response from MISO. From what I can understand reading the TMC5160 datasheet, bit 39 is 1 (read/write selecting write), bits 38-31 define the register (0x00 corresponding to GCONF), bit 8 enables diag1 on motor stall (for sensorless home), and lastly bit 3 enables multistep_filt for stealthchop optimization w/ external step source. I assume the second 8-byte block is supposed to be the response from the 5160 reading back that these were set correctly.

The thing that’s got me scratching my head with this is the fact that if the Octopus is powered off for around 45 minutes and then powered on, every single driver works fine. I can read all the data from DUMP_TMC, I can even move the steppers (although I still have some bugs to work out with configuring sensorless homing) but the moment I FIRMWARE_RESET or power cycle the board, every single driver plays dead.

I’m running soft SPI, here’s a snippet of how one of the two x steppers is configured:

[stepper_x]
step_pin: PC13
dir_pin: PC14
enable_pin: !PE6
microsteps: 16
rotation_distance: 40
endstop_pin: tmc5160_stepper_x:virtual_endstop
position_endstop: 0
position_max: 1100
homing_speed: 20

[tmc5160 stepper_x]
#uart_pin: PG14
#spi_speed: 4000000
cs_pin: PG14
#spi_bus: spi4
spi_software_miso_pin: PE13
spi_software_mosi_pin: PE14
spi_software_sclk_pin: PE12
interpolate: true
sense_resistor: 0.075
diag1_pin: ^!PF0
driver_SGT: -16
run_current: 0.800
stealthchop_threshold: 0

I’ve tried hardware SPI, I’ve tried many different SPI speeds, I’ve tried disabling the SD card and LCD (which are on the same spi4 bus) with a static_digital_output:

[static_digital_output disable_display_sdcard_expdhdr]
pins: PE11, PB12, PF14

No change. I’m not entirely sure where in the Klipper firmware soft SPI is configured and in what mode it is operating; I’m still pretty new to the C language, embedded development, and protocols and whatnot. I was unable to get a scope view of the drivers working today, but I promise they do work after sitting off for a long enough time. I will update this post on Monday if I have any success then. TIA!

[m32825]

If there is a separate power supply for the motor driver, the grounds need to be tied together so that the driver can see what you’re sending. Scope it from the driver side to see if it looks the same.

 – Carl

[m32825]

I added this wire from board ground to driver ground to put them on the same reference. Before that the signals at the driver end looked wonky.

[pporcaro]

Gotcha! I probed spi4 from the SPI header and not the driver, sounds like a good place to start. I wouldn’t be surprised if a ground was left floating, I’ll try adding a jumper from board ground to driver ground and see what happens Monday.

As a sidenote, I don’t have the bed power/bed out hooked up since this printer has separate temperature controllers for the bed. I didn’t remember seeing anything with the bed power circuit that’s related to any of this, but I suppose it wouldn’t hurt to try adding a jumper from board/driver ground to bed ground just in case leaving the bed ground floating is contributing.

Thanks for the tips – I will post an update Monday!

[pporcaro]

Quick update – despite sitting unpowered all weekend, still no communication back from the drivers.

I probed MOSI and MISO directly at the driver (not at the SPI header) and the signals from MOSI are correct, no funkiness happening there. There is no response at all from the driver on MISO directly at the driver socket, so I’m imagining there has to be something wrong with the driver. I will work through switching out all 10 of the drivers I have to see if any of them will communicate.

Above is the scope when probing both the SPI header (yellow trace is MOSI, light blue is MISO, and magenta is CLK), and the dark blue trace is probing MOSI directly at the driver socket. Note that MOSI is 3.3v at the SPI header but goes through a buffer gate and is converted to 5v for the driver.

I also probed MISO at the driver, and it stayed pinned at 5v – no signal whatsoever, just noise. Of course, I checked CLK and CS at the driver as well; CLK pulsed directly in line with CLK at the SPI header, and CS pulled down to ground as soon as the transmission started as it should, switching back to 5v when transmission stopped.

As suggested by Carl, I added a jumper from ground at the driver to the board ground, no change. Probing various grounds across the board, all were at 0v, no funkiness there either. I even added a ground jumper to the bed ground as I mentioned above, as expected, no change.

Maybe I’m missing something here, I really don’t know. It seems I’ve done everything right. This has become such a nightmare.

One final note for now – I had flashed the STM32 through USB with the BTT Pi 2. BTT instead suggests flashing via a microSD card, which I will try, but I don’t expect anything to change. I will update if this miraculously fixes the issue, otherwise I may just order some more drivers and see if they actually work.

[m32825]

I like how thorough you are. I must admit to suffering from a case of “scope envy”….

What does the driver enable line look like?

[pporcaro]

Driver enable is getting 5v, I also checked the driver HV supply and it’s at 24v. I’m not even sure where to go from here, haha.

I’ve put a ticket in for BTT support, so I’ll see if they have anything helpful. I have a feeling something is faulty within the driver itself, or perhaps there was a power surge when power cycling the board at some point that killed them. I’m just appalled that all 10 of them would die. I’d never pulled the drivers or stepper motor connectors while powered, I always powered the board down before connecting/disconnecting anything.

I will update once I have more info!