[BUG] TMC5160 v1.2 Testing X Y Z E connection... Error: All HIGH after heating

[superkefir]

Bug Description

Hello! Last week i have a battle with my TMC5160. On boards: SKR 1.3(2pcs) and SKR 1.4 Turbo I got the same problem with TMC5160 1.2 from BTT (X Y Z E Z2) Version of Marlin 2.0.5.2->2.0.5.3

When power on the board and send M122 i have the message that connection is ok and the register of the drivers. After sending M190 S90 (or M109 S220 T0) the printer sending busy in terminal and after that if i send M122 i have connection error: all high for all drivers until i reboot the board. It can prints but can't change threshold values and prints very loud. Before sending one if this commands it moves in all positions without any problems and M122 respond good for all drivers. If i heat the bed and the extruder by sending M140 S90 and M104 S220 T0. The response is good.

My Configurations

Marlin.zip

Steps to Reproduce

1) Turn on 2) Send M122 3) Send M190 Sx or M109 Sx T0 4) Wait until it heats 5) Send M122

Additional Information

[GMagician]

Maybe some electrical noise on spi wires due to heater pwm?

[superkefir]

But the heater works fine when i send M140 Sx (from 30 to 100). It's just heat and then M122 is normal. Also i disconnect all TMC5160 and check with only one on each axis. It's the same situtation. Also i checked with only extruder heater and only bed heater that is 220v and connected through the solid-state relays.

[superkefir]

I'm confused. After M190 Sx i send M122, then i see bad response and send M502 and M500 and again M122. And the connection is back. If i power on the board and send M502 -> M500 -> M190 Sx the problem is the same. If after M190 Sx a send M502 -> M500 and then try M190 Sx or M109 Sx T0 the connection is ok.

[thinkyhead]

When the board is "powered on" does it have the full 12V? The 12V power is needed for TMC drivers to be able to accept and retain settings.

[superkefir]

I checked with multimeter it has 24v. The heater of extruder when it turns on the same ~24v.

[superkefir]

I have some idea. I can't check LPC1769 on version below 2.0.5.0 So i check the version 2.0.5.0, 2.0.5.1 2.0.5.2 2.0.5.3 Everything the same. But have some consistent patterns. So my steps: 1) Turning the board 2) Check connections of driver by M122 3) It's ok so i load factory default by M502 and M500 to save it. 4) M190 S30 (or other temperature, it doesn't matter) 5) Waiting for response and send M122 - getting connection lost 6) Send M502 or M501 - it's resume connection. 7) Send M190 Sx 8) Waiting and send M122 again - everything ok.

So the idea that the difference between commands M190 and M140 do the same temperature, but the second command doesn't broke the connection and the first does. But connection turns back after restoring factory defaults. I open the file printcounter.h to check what can broke the EEPROM settings. But my knowledge of the Marlin is not enough to find the problem. Only possible reasons:

> #if USE_REAL_EEPROM
>   // round up address to next page boundary (assuming 32 byte pages)
>   #define STATS_EEPROM_ADDRESS 0x40
> #else
>   #define STATS_EEPROM_ADDRESS 0x32
> #endif

or maybe

   #if USE_REAL_EEPROM || defined(CPU_32_BIT)
      typedef uint32_t eeprom_address_t;
    #else
      typedef uint16_t eeprom_address_t;
    #endif

But i can't find a working version for LPC1769 that won't broke the connection (or EEPROM data) so maybe it will helps to find what's the reason of such behavior. But maybe you can help me to find how to fix it without buying fourth board of SKR.

[GMagician]

You may send m503 to see current values. Comparing them with before and after heating you may see what's different. But I think it's not something related to eeprom corruption but something else. I can't dig more because I don't have a SKR board. Something you may do is an "M43" (not sure if with W argument) before and after heating, just to see if some pin has changed its "I/O" state.

N.B. M43 requires firmware to be compiled with PINS_DEBUGGING

[superkefir]

I only see that the pins are changed but i knew it before, cause there is no connection. But what can broke in settings by command M190 that doesn't by M140. M122before.txt M122after.txt M503 before.txt M503 after.txt M43 before.txt M43after.txt

[GMagician]

TMC_SW_SCK is 1 when ok and 0 when not, that's not good. Even in case of error clock should be in idle state on end of communication

[superkefir]

Is it possible that the M190 command when stops the command to printer may depend on the other work of printer that's broke connection or can't return some functions back? At the same time M140 works good. And after M501 when the connection is broken (or the connection is working but some other settings are broken, that shows that connection is lost) it starts working normal and the M190 command doesn't brake it again.

[superkefir]

It seems like TMC_SW_SCK is 0 after M501 command.

[GMagician]

m501 calls reset_stepper_drivers and there I think it reprogram TMC_SW_SCK.

First of all it's important to know if in your board is used software or hardware SPI...

[superkefir]

I mean after the M190 the command M43 shows TMC_SW_SCK 0 and M501 doesn't change it back to 1.

[GMagician]

Both M140 and M190 call restore_stepper_drivers when AUTO_POWER_CONTROL is defined and M190 just wait temp is reached. No other differences with M140. You said that M140 has no problems. What if you call M140, wait bed temperatures reached and then M122?

[superkefir]

It's all ok. You can check the attached terminal info with M43 -> M140 S30 -> M43 and M122 M140.txt

[superkefir]

The same situation with M104 and M109. M104 it's ok and M109 broke the drivers. M104_M109.txt

[GMagician]

Do you have some led lighting (PRINTER_EVENT_LEDS or similar) ? TMC_SW_SCK and RGB_LED_G_PIN seems to share same pin

[superkefir]

Marlin.zip I have

#define RGB_LED
#if EITHER(RGB_LED, RGBW_LED)
  #define RGB_LED_R_PIN 5
  #define RGB_LED_G_PIN 4
  #define RGB_LED_B_PIN 6
  #define RGB_LED_W_PIN -1
#endif

[superkefir]

Yes it's worked the M190 and M109 now doesn't broke anything. I must thank you for your help. I spent 5 days finding the problem, and the solution was so close.

[GMagician]

Try to disable it...

[superkefir]

Thank you!

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.