Azteeg x5 GT with BSD2660 and miniViki Wifi not working together: TMC connection error

Hello there people! I am hoping to find some help with this.

Trying to assemble my first 3D printer from scratch (only owned a CR-10s before, that I upgraded a lot). I chose the azteeg x5 gt and want to run marlin 2.0 on it, because I want to run a dual Z axis with two steppers and the documentation of panucatt seems non existent on that issue...

I have compiled Marlin 2.0.0.4 bugfix from git for the Azteeg 5X GT.
Without the LCD (panucatt Mini Viki Wifi) the board initializes and the steppers (Bigfoot BSD2660) all register as ok. I can send M122 and the steppers move when homing.

However, when I connect the LCD the display comes on when booting, shows some noise before the marlin logo, then it reports "TMC connection error" and when sending M122 from the pc, the drivers do not report back:

SENDING:M122
Testing X connection... Error: All LOW
Testing Y connection... Error: All LOW
Testing Z connection... Error: All LOW
Testing E connection... Error: All LOW

I tried to investigate this and have been googling up and down the internet, but I can't figure it out. I think it has something to do with the SPI channel of the LCD maybe interfering? Does that even make sense technically?

Also I have tried with the tx/rx lines of the wifi backpack connected to the board and disconnected, because I thought that might be an issue, but it makes no difference.

I would be super happy if anyone could shed some light on this and help me debug. Thanks a bunch in advance!

Well I would check for obvious pin conflicts first.

Enable Debug pins M43 In Configuration_adv.h
Setup without LCD and send a M43 and capture the result
Enable the LCD and create a second M43 capture.

Compare the two files, see if enabling LCD changed anything important.

@Dust: Thank you for the tipp! I have used my morning coffee time to gather some more info.

Okay I have compiled the firmware without LCD support and run M43, then I have done it again with LCD support being compiled in.

I have made a diff to see exactly what has changed:

These lines:

PIN: 0.02 (A 2)     Analog in =  1011   Input  = 1
PIN: 0.03 (A 3)     Analog in =   860   Input  = 0
PIN: 0.15        SCK_PIN                                Input  = 0
PIN: 0.16                               Input  = 1
PIN: 0.17        MISO_PIN                               Input  = 1
PIN: 0.18        MOSI_PIN                               Output = 1
PIN: 1.18                               Output = 1
PIN: 1.19                               Output = 1
PIN: 1.20                               Output = 0
PIN: 1.21                               Output = 0
PIN: 1.23        SDSS                                   Output = 1
.                SERVO0_PIN                             Output = 1
PIN: 1.30 (A62)     Analog in =   511   Input  = 0
PIN: 1.31 (A63)     Analog in =   706   Input  = 0
PIN: 2.06                               Input  = 0
PIN: 2.11                               Input  = 1
PIN: 3.25                               Input  = 1
PIN: 3.26                               Input  = 1
PIN: 4.28                               Input  = 0

have become these lines when LCD is attached:

PIN: 0.02 (A 2)     Analog in =  1002   Input  = 1
PIN: 0.03 (A 3)     Analog in =   927   Input  = 0
PIN: 0.15        DOGLCD_SCK                             Input  = 0
.                SCK_PIN                                Input  = 0
PIN: 0.16        DOGLCD_CS                              Output = 1
PIN: 0.17        MISO_PIN                               Input  = 0
PIN: 0.18        DOGLCD_MOSI                            Output = 1
.                MOSI_PIN                               Output = 1
PIN: 1.18        SD_DETECT_PIN                          Analog in =     0
PIN: 1.19        STAT_LED_RED_PIN                       Output = 0
PIN: 1.20        STAT_LED_BLUE_PIN                      Output = 0
PIN: 1.21        SDSS                                   Analog in =     0
PIN: 1.23        SERVO0_PIN                             Output = 1
PIN: 1.30 (A62)     Analog in =   569   Input  = 0
PIN: 1.31 (A63)  BEEPER_PIN                             Output = 0
PIN: 2.06        DOGLCD_A0                              Input  = 1
PIN: 2.11        BTN_ENC                                Analog in =     0
PIN: 3.25        BTN_EN1                                Input  = 0
PIN: 3.26        BTN_EN2                                Analog in =     0
PIN: 4.28                               Input  = 1

Here is a github gist I created with the complete output of both:
[gist.github.com]

Code formatting and forum software... ugh.

I have to go to work now, so I can't analyze the output properly right now.
It does seem to me like a couple of pins are conflicting, though. Sadly I have no clue on how to change that.

Edited 2 time(s). Last edit at 03/10/2020 05:47AM by xnopasaranx.

Doesn't look like any issues there...
The SD card is moved to the one on the LCD so the SDSS pin changed.

The next suspect is SPI..
Both LCD and the Stepper drivers use SPI...

I know there are different modes for SPI, I wonder if the LCD uses a different one to what is required by the steppers..
Sadly I don't know how to check this...

Quote
Dust
Doesn't look like any issues there...
The SD card is moved to the one on the LCD so the SDSS pin changed.

The next suspect is SPI..
Both LCD and the Stepper drivers use SPI...

I know there are different modes for SPI, I wonder if the LCD uses a different one to what is required by the steppers..
Sadly I don't know how to check this...

Yes that was my assumption as well... SPI seems to be the culprit. I wonder why this fails with the miniViki Display. I followed this guys tutorial on youtube: [www.youtube.com] but he does not mention which display he uses.

So thus far I have gathered that there are numerous things that could be the root cause of my problem here:
- EMI: The BSD2660s are on sockets, so that can't be the issue, but the flat cable connecting the display might introduce some interference from wherever. As it is a test setup right now, this could be the endstop cables (leafswitches with COM, NC), the stepper motor cables themselves or some other crap running amok on my workbench (lighting? magic? background radiation?)
- SPI bus problems: I think this is more likely, as I did not have any EMI issues running smoothieware

I have found this article on hackaday regarding SPI debugging: [hackaday.com]
Will have a look at that when I am back home, it explains the protocol as well as common issues. So maybe that'll help me understand what it might be and narrow it down.

I own a DSO (Rigol DS1054z) which can supposedly decode SPI signals, so I might finally get a chance to use that feature. But having a look at the signal won't hurt, just to make sure it looks clean and rule out EMI.

EDIT: @Dust I didn't read your last sentence there. Maybe that is what I should try to check first before I whip out the measuring tools and confuse myself even more. I also filed an issue on github, maybe the devs can help me narrow this down.

Edited 1 time(s). Last edit at 03/10/2020 04:15PM by xnopasaranx.

I was also thinking use a scope. It may be able to tell you if the spi mode has changed and or the spi speed.

Since I opened this thread, I went back to smoothieware to try and get my printer printing again. Had a bunch of problems where I was not satisfied with the documentation and just didn't get it. I asked for help on the proper smoothieware forum (hosted at makerforums) and didn't really get any help, so I went back to marlin after some kindergarten scene drama unpleasentness.

I am very happy to report, that my printer is running close to perfect with marlin 2.0 now! I am still getting the "TMC Connection Error" when the miniViki is connected, but the steppers seem to have configured correctly regardless (unlike with my smoothieware attempts, where they were running but also screaming constantly and not power down after moving... like I said, apparently I am too dumb to understand how to configure that properly).

Not sure if I will leave the miniViki display or switch it out for an I2C display module at some point, but for now everything is peachy.

Just wanted to thank everyone who gave me some advice here, I have been lurking here for so long and since I finally have my own printer, was really glad that the reprap scene is so friendly and welcoming.
I will however say this: I will never ever again buy a smoothieware board, be it an original, a forked but official one or a chinese knockoff. I will also never recommend smoothieware to anyone. What a bunch of elitist snobs.

Edited 1 time(s). Last edit at 05/16/2020 10:40AM by xnopasaranx.

SOLUTION: I believe I have solved the problem I had. I have configured #define SPI_SPEED SPI_HALF_SPEED and pulled the latest bugfix-2.0.x and the problem has gone away. Pretty sure it is the newer version though, as the error does not come up even with SPI_HALF_SPEED not set and I had tried setting it in older versions without any success.

I am a happy printer