[BUG] MKS TS35-R V2.0 with MKS Robin E3D V2.0 not working as expected

[quiret]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

I am trying to use the Markerbase MKS TS35-R V2.0 screen using Marlin 2.1.x bugfix from a few months ago. When I connect the screen to my MKS Robin E3D v1.1 across the EXP1/EXP2 pins I get a garbled mess of random colors. But when I put in a SD card it - for some random reason - gets to output a valid picture on the TFT.

I dug into the Marlin source and I realized that the TFT is using this source file for SPI communication across the HAL by sending this buffer first. I suspect the buffer is interpreted as raw image data and not as commands/registers sequence because the DCX/RS pin is not used.

Bug Timeline

new issue, did search but nobody asked about it

Expected behavior

I did expect that the screen would work properly along with the touch-screen because the SPI is semi-fine. There is no reason beyond the not-supported-with-this-screen bootloader that the TS35 would fail to work.

Actual behavior

The screen is a mess unless I glitch the board strongly enough to get into a valid screen state.

Steps to Reproduce

1. build Marlin using the provided configs
2. flash Marlin onto the control board
3. plug the screen using the EXP1/EXP2 interface
4. turn on the board
5. verify that instead of the bootscreen you get a garbled mess

Version of Marlin Firmware

2.1.x bugfix

Printer model

custom

Electronics

Makerbase MKS Robin E3D v1.1
MKS TS35-R V2.0

Add-ons

No response

Bed Leveling

No response

Your Slicer

No response

Host Software

No response

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

configs.zip

Anyway, I appreciate the work put into this free software because it is a good starting point. Even if it is imperfect the amount of dedication by this open internet community is amazing! Let it be known that your work is not wasted and even commercial products are relying on your unwasted talent.

DISCLAIMER: the mentioned control board has a very limited EXP1/EXP2 interface tied directly in part to the SD card slot; I do NOT recommend trying this hardware combination at home! 😉

[ellensp]

TFT_A0_PIN is data / cmd line

static void WriteData(uint16_t Data) { Transmit(Data); }
static void WriteReg(uint16_t Reg) { WRITE(TFT_A0_PIN, LOW); Transmit(Reg); WRITE(TFT_A0_PIN, HIGH); }

[quiret]

TFT_A0_PIN is data / cmd line

static void WriteData(uint16_t Data) { Transmit(Data); } static void WriteReg(uint16_t Reg) { WRITE(TFT_A0_PIN, LOW); Transmit(Reg); WRITE(TFT_A0_PIN, HIGH); }

Thank you for the quick response. I admit that my assumption was wrong and the SPI implementation appears fine. But I am still faced with this strange TS35 screen issue. May have to debug the hardware and come back.

[ellensp]

You should correct the 1000's of pin redefinition warnings, in case this is causing issue

in Marlin/src/pins/stm32f1/pins_MKS_ROBIN_E3_common.h
wrap endstops in if blocks

//
// Limit Switches
//
#ifndef X_STOP_PIN
   #define X_STOP_PIN                          PA12
#endif
#ifndef Y_STOP_PIN
   #define Y_STOP_PIN                          PA11
#endif
#ifndef Z_STOP_PIN
   #define Z_STOP_PIN                          PC6
#endif

same with the lcd pins

#if HAS_WIRED_LCD

  #define BEEPER_PIN                 EXP1_01_PIN
  #define BTN_ENC                    EXP1_02_PIN
  #ifndef LCD_PINS_ENABLE
     #define LCD_PINS_ENABLE            EXP1_03_PIN
  #endif
  #ifndef LCD_PINS_RS
     #define LCD_PINS_RS                EXP1_04_PIN
  #endif

And use stop pin in config (will automatically be allocated to min or max depending if homing is set to min or max)

#define X_STOP_PIN PA2
#define Y_STOP_PIN PB1
#define Z_STOP_PIN PB10

This removes all the pin redefinition warnings

[quiret]

@ellensp Thank you for the hint. I have managed to fix the TFT and XPT2046 SPI implementations and will post a patch soon. The SPI on those devices works flawlessly now after my changes.

[github-actions]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[github-actions]

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.