Who manufactured the step-sticks?
Have you tried placing them in your board one by one to see if one might be faulty and dragging down the rest? Obviously good ones should be able to properly respond to DUMP_TMC
All STM32F446ZET6 have the same set of pins. Pins have different functions assigned to them. Some can be used for PWM, some are just digitial IO, some are able to measure analogue values (ADC) etc. Another set of pins have special bus functions like SPI, I2C, UART etc associated with them.
For example:
PA1, PA2 and PA8 are PWM capable pins, so they could be used for controlling heatbed, fans, hotends or LEDs, etc
PF3 and PF4 are analogue to digital (ADC) capable pins, so they could be used for measuring temperatures (which reads an analogue resistance value or rather the voltage drop over such resistors)
It is up to the manufacturer of your board, which pins he uses for which function or if at all.
So, one manufacturer might choose to assign PA8 to a hotend and provide the needed connectors, while another uses PA1 for the same purpose.
Klipper uses its cfg file to determine just that: Which pin is used to control which aspect of the printer.
Thanks I needed to know that. I found my issue, going back to Marlin firmware, I issued a M122, it showed the driver connection error, I had a TMC2226 uart driver in the extruder spot, that working driver stopped marlin from showing TMC Connection error on the display. I replaced the tmc2226 with a LV8729 thinking the TMC2226 Uart driver may not work with the TMC5160 spi drivers. it did not fix the connection error, but marlin firmware when boot shows the TMC connection error now on the screen. but yet marlin lets you run, and print . I guess marlin firmware sets the drives to standalone. Now to see why the 5160 not working with spi.
Good day!
So, I bought Mellow FLY-SHT42 and FLY-UTOC-3 boards, connected them. At the same time, I updated the firmware on all MCUs.
At the moment the configuration is:
RPi 3B+ => USART => BTT GTR 1.0 + BTT M5
and to the same RPi 3B+ => USB => FLY-UTOC-3 => CAN => FLY-SHT42
BTT GTR 1.0 has two drivers (X and Y) BTT TMC5160 v1.2 connected via SPI.
Before installing the “moving” of the head on the FLY-SHT42, everything worked fine, I decided to minimize the number of wires.
Now the error “TMC stepper_x failed to init: Unable to write tmc spi ‘stepper_x’ register GLOBALSCALER” and “TMC stepper_y failed to init: Unable to write tmc spi ‘stepper_y’ register GLOBALSCALER” appears periodically.
You can get rid of it after long and painful reboots (power off and on) of the 3D printer.
I did an experiment, deleted all the settings associated with FLY-SHT42, i.e. in fact, Klipper did not see this MCU, but the error remained.
completely disconnected FLY-SHT42 from FLY-UTOC-3 (4 CAN wires) and removed the can0 interface on RPi… and the error remained;
disconnected motors X and Y from BTT GTR 1.0… the error is in place;
changed connection mode (changed jumpers) of X and Y drivers from SPI to UART… same error;
replaced two BTT TMC5160 v1.2 (X and Y) with BTT TMC2209 v1.2… the error is GONE.
So, it turns out that on the day I installed FLY-SHT42 in a 3D printer, the software SPI disappeared on the BTT GTR 1.0, or did two BTT TMC5160 v1.2 fail SIMULTANEOUSLY?
The most interesting thing is that on the same pins, but only in UART mode, BTT TMC2209 v1.2 works fine… by the way, it works fine, but on hardware SPI, and MAX31855K wired to BTT GTR 1.0
P.S. To eliminate the problem with BTT GTR 1.0, I will connect the Mellow FLY PT100 thermistor board to the driver’s free space, which uses the same software SPI as BTT TMC5160 v1.2… and something tells me that it will work without problems.
Note that if the driver is on a shared SPI bus with multiple devices then be sure to fully configure every device on that shared SPI bus in Klipper. If a device on a shared SPI bus is not configured, then it may incorrectly respond to commands not intended for it and corrupt the communication to the intended device. If there is a device on a shared SPI bus that can not be configured in Klipper, then use a static_digital_output config section to set the CS pin of the unused device high (so that it will not attempt to use the SPI bus). The board’s schematic is often a useful reference for finding which devices are on an SPI bus and their associated pins.
This means other SPI devices on the same SPI bus that are not fully configured / incorrectly configured / have issues with certain SPI modes can indeed spoil your fun.
