BTT GTR and TFT35v3 E3 not working

[bakaufman]

I am running an TFT35 E3 on a GTR board with Klipper. I DL'd the config.ini from BTT and the Notouchscreen binary "BIGTREETECH-TFT35_V3.0_E3.26.x.bin" and put them on an SD, inserted and restarted. Now it just says ST7920 Ready. Please let me know what I need to change.

[teeminus]

So you see the "NoTouchFw V1.2" on the top and below that "ST7920Emulator ready", correct? If that's the case, please check your klipper config. How does your klipper display config look like?

[bakaufman]

Super quick response. +2 Correct on what you see on screen. I also get the Bin ->.CUR in on the SD card.

# EXP1 / EXP2 (display) pins
########################################

# display section not tested - pinout should be correct but my LCD did not work yet

[board_pins]
aliases:
    # EXP1 header
    EXP1_1=PC11, EXP1_3=PC10, EXP1_5=PG8, EXP1_7=PG6, EXP1_9=<GND>,
    EXP1_2=PA15, EXP1_4=PA8, EXP1_6=PG7, EXP1_8=PG5, EXP1_10=<5V>,
    # EXP2 header
    EXP2_1=PB14, EXP2_3=PD10, EXP2_5=PH10, EXP2_7=PB10,  EXP2_9=<GND>,
    EXP2_2=PB13, EXP2_4=PB12, EXP2_6=PB15, EXP2_8=<RST>, EXP2_10=<NC>
    # not sure on this: Pins EXP2_1, EXP2_6, EXP2_2 are also MISO, MOSI, SCK of bus "spi2"

# See the sample-lcd.cfg file for definitions of common LCD displays.

[display]
lcd_type: st7920
cs_pin: EXP1_4
sclk_pin: EXP1_5
sid_pin: EXP1_3
encoder_pins: ^EXP2_5, ^EXP2_3
click_pin: ^!EXP1_2
#kill_pin: ^!EXP2_8

[output_pin beeper]
pin: EXP1_1

[teeminus]

Have you restarted Klipper after installing the firmware?

[bakaufman]

FIRMWARE_RESTART and RESTART a couple of times. Could the inclusion of any of these files be the problem? This is an E3 screen to be clear.

[teeminus]

Those files from BTT are not required for this firmware, you can remove them from the SD card.

You could try this config which works for the TFT35v3 E3 and the SKR 1.4 turbo:

[display]
lcd_type: st7920
cs_pin: EXP1_7
sclk_pin: EXP1_6
sid_pin: EXP1_8
encoder_pins: ^EXP1_5, ^EXP1_3
click_pin: ^!EXP1_2

[bakaufman]

something has gone sideways. deleted everything other than the config.ini and your .bin file, inserted SD card and rebooted. It says illegal flash app.

[teeminus]

Make sure you use the correct binary file for your display. If you have successfully flashed the TFT, there is no need to reflash it again.

If you have seen the expected content (https://github.com/teeminus/NoTouchScreenFirmware/issues/5#issuecomment-776002101) the issue is most likely in the klipper config.

[bakaufman]

FWIW - To regress to prior state I had to have those files that you said were unnecessary.

What does your alias look like for SKR?

[bakaufman]

My aliases above are correct for marlin. What might be confusing is the different terminology between Marlin and Klipper for display pins.

Klipper: Marlin? cs_pin: LCD_RS? sclk_pin: LCD_D7 sid_pin: LCD_EN encoder_pins: BTN_ENC2, BTN_ENC1 click_pin: BTN_ENC

Other options are LCD_D4(D6, D7), MISO, MOSI, SD_SS, SCK, SD_DETECT

[bakaufman]

cs_pin = LCD_PINS_RS = PA8 = EXP1_4, so the skr aren't going to be equivalent.

[teeminus]

I don't know your particular display or mainboard, but I noticed that the display config for the TFT35v3 E3 in the wiki differs for the other. You could try this config:

[board_pins]
aliases:
    EXP1_1=PC11, EXP1_3=PC10, EXP1_5=PG8, EXP1_7=PG6, EXP1_9=<GND>,
    EXP1_2=PA15, EXP1_4=PA8, EXP1_6=PG7, EXP1_8=PG5, EXP1_10=<5V>,
    EXP2_1=PB14, EXP2_3=PD10, EXP2_5=PH10, EXP2_7=PB10,  EXP2_9=<GND>,
    EXP2_2=PB13, EXP2_4=PB12, EXP2_6=PB15, EXP2_8=<RST>, EXP2_10=<NC>

[display]
lcd_type: st7920
cs_pin: EXP1_7
sclk_pin: EXP1_6
sid_pin: EXP1_8
encoder_pins: ^EXP1_5, ^EXP1_3
click_pin: ^!EXP1_2

[bakaufman]

I tried that and it didn't work. for example, my last post I was able to track down the cs_pin to the EXP1_4, which was what the original GTR settings, rather than the SKR settings.

What I really need is the Marlin equivalent for PIN names.

[bakaufman]

I tried to crack the code with skr1.4, but there are rewiring variants that really confuse things for me.

[bakaufman]

I have tried both variants herein:

########################################
# EXP1 / EXP2 (display) pins
########################################

# display section not tested - pinout should be correct but my LCD did not work yet

[board_pins]
aliases:
    # EXP1 header
    EXP1_1=PC11, EXP1_3=PC10, EXP1_5=PG8, EXP1_7=PG6, EXP1_9=<GND>,
    EXP1_2=PA15, EXP1_4=PA8, EXP1_6=PG7, EXP1_8=PG5, EXP1_10=<5V>,
    # EXP2 header
    EXP2_1=PB14, EXP2_3=PD10, EXP2_5=PH10, EXP2_7=PB10,  EXP2_9=<GND>,
    EXP2_2=PB13, EXP2_4=PB12, EXP2_6=PB15, EXP2_8=<RST>, EXP2_10=<NC>
    # not sure on this: Pins EXP2_1, EXP2_6, EXP2_2 are also MISO, MOSI, SCK of bus "spi2"

# See the sample-lcd.cfg file for definitions of common LCD displays.

## "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays & GTR example config
[display]
lcd_type: st7920
cs_pin: EXP1_4
sclk_pin: EXP1_5
sid_pin: EXP1_3
encoder_pins: ^EXP2_3, ^EXP2_5
click_pin: ^!EXP1_2
#kill_pin: ^!EXP2_8

[output_pin beeper]
pin: EXP1_1

#sample-lcd.cfg CR10/Ender 3
#[display]
#lcd_type: st7920
#cs_pin: EXP1_7
#sclk_pin: EXP1_6
#sid_pin: EXP1_8
#encoder_pins: ^EXP1_5, ^EXP1_3
#click_pin: ^!EXP1_2

#[output_pin beeper]
#pin: EXP1_1

[bakaufman]

So digging around in a generic RAMPS with Full discount on Marlin: LCD_PINS_RS (CS chip select, SS chip slave select) -----So CS is RS pin LCD_PINS_ENABLE (SID (MOSI))------so SID is the LCD enable pin LCD_PINS_D4 (SCK (CLK) clock)------so SCLK is D4 output_pin beeper -------BEEPER_PIN is obvious

a little less clear BTN_ENC_EN is LCD_PINS_D7 (detect the presents of the encoder) -----click pin? (since it is always defined alone) encoder pins ---------btn en1 and btn en2 (since they are generally defined together? click pin ----

so for GTR: lcd_type: st7920 cs_pin: EXP1_4. --correct, this is the RS pin sclk_pin: EXP1_5 ---this is correct, D4 sid_pin: EXP1_3 ---this is correct, ENABLE encoder_pins: ^EXP2_3, ^EXP2_5 ---this too is correct, EN1 and EN2 click_pin: ^!EXP1_2 ---this is correct, BTN_ENC [output_pin beeper] pin: EXP1_1 ---this is corrected, BEEPER_PIN

I went ahead and forked the repo and compiled as an E3 just in case the bins wrong but nothing changed.

[teeminus]

From the TFT35v3E3 schematics I saw that there is another connector which has the power pins at the same locations as the EXP1 connector. Have you tried using the other connector insteat (try both pin configs please)? There seems to be some confusion about the pinout here: https://github.com/bigtreetech/BTT-TFT35-E3-V3.0/issues/59

The encoder uses two pins for direction and one pin for the click. For the rotation two pins are used because otherwise the software wouldn't be able to tell in which direction the encoder has been turned. But the encoder is handled by klipper directly.

If you can't get the v1.2 firmware to work, please try the v1.1 firmware. This has been reported working by @Sineos: https://github.com/teeminus/NoTouchScreenFirmware/issues/2#issuecomment-772591270

[Sineos]

I have to correct my working configuration to:

[board_pins]
aliases: 
    EXP1_1=P1.30, EXP1_3=P1.18, EXP1_5=P1.20, EXP1_7=P1.22, EXP1_9=<GND>,
    EXP1_2=P0.28, EXP1_4=P1.19, EXP1_6=P1.21, EXP1_8=P1.23, EXP1_10=<5V>,
    EXP2_1=P0.17, EXP2_3=P3.26, EXP2_5=P3.25, EXP2_7=P1.31, EXP2_9=<GND>,
    EXP2_2=P0.15, EXP2_4=P0.16, EXP2_6=P0.18, EXP2_8=<RST>, EXP2_10=<NC>

[display]
lcd_type: st7920 
cs_pin: EXP1_4
sclk_pin: EXP1_5
sid_pin: EXP1_3
encoder_pins: ^EXP2_3, ^EXP2_5
click_pin: ^!EXP1_2

[output_pin beeper]
pin: EXP1_1

I noticed something very strange:

• During update to v1.2 I ended up with the same problem as described here. Either only "ST7920Emulator ready" displayed or blank screen with only the header
• Klipper service restart / RESTART / FIRMWARE_RESTART / Reset MCU via reset button would not bring the display back.
• I tried several combinations of configurations to no avail

--> In the end it turned out for my board and my Klipper install that I had to do a full power cycle of the printer board until it would pick up a changed configuration and be able to initialize. If not powered-cycled it would remember the old config (or so it seemed to me at least)

On my side I still have the problem that I need potentially multiple power cycles with following RESTART and FIRMWARE_RESTART to have the display properly initiated. The ugly thing is that failing to initialize the display properly can lead to

• a garbled screen
• "ST7920Emulator ready"
• a black screen with only the firmware title So when setting up a new display it can be difficult to distinguish between wrong configuration and a failed display initialization.

My recommendation when doing this: setup the new config --> powercycle the board --> sudo service klipper restart --> FIRMWARE_RESTART

Maybe paranoid but I had my fingers burned and spent some hours screaming at the stupid display

[bakaufman]

From the TFT35v3E3 schematics I saw that there is another connector which has the power pins at the same locations as the EXP1 connector. Have you tried using the other connector insteat (try both pin configs please)? There seems to be some confusion about the pinout here: bigtreetech/BTT-TFT35-E3-V3.0#59

The encoder uses two pins for direction and one pin for the click. For the rotation two pins are used because otherwise the software wouldn't be able to tell in which direction the encoder has been turned. But the encoder is handled by klipper directly.

If you can't get the v1.2 firmware to work, please try the v1.1 firmware. This has been reported working by @Sineos: #2 (comment)

I guess the thing to ask here is if the connectors were working on marlin whether they are correct now? I just migrated from a functional current Marlin printer to Klipper. I didn't move the plugs. If that solves this question, then I won't move them.

[bakaufman]

I have to correct my working configuration to:

[board_pins]
aliases: 
  EXP1_1=P1.30, EXP1_3=P1.18, EXP1_5=P1.20, EXP1_7=P1.22, EXP1_9=<GND>,
  EXP1_2=P0.28, EXP1_4=P1.19, EXP1_6=P1.21, EXP1_8=P1.23, EXP1_10=<5V>,
  EXP2_1=P0.17, EXP2_3=P3.26, EXP2_5=P3.25, EXP2_7=P1.31, EXP2_9=<GND>,
  EXP2_2=P0.15, EXP2_4=P0.16, EXP2_6=P0.18, EXP2_8=<RST>, EXP2_10=<NC>

[display]
lcd_type: st7920 
cs_pin: EXP1_4
sclk_pin: EXP1_5
sid_pin: EXP1_3
encoder_pins: ^EXP2_3, ^EXP2_5
click_pin: ^!EXP1_2

[output_pin beeper]
pin: EXP1_1

I noticed something very strange:

• During update to v1.2 I ended up with the same problem as described here. Either only "ST7920Emulator ready" displayed or blank screen with only the header
• Klipper service restart / RESTART / FIRMWARE_RESTART / Reset MCU via reset button would not bring the display back.
• I tried several combinations of configurations to no avail

--> In the end it turned out for my board and my Klipper install that I had to do a full power cycle of the printer board until it would pick up a changed configuration and be able to initialize. If not powered-cycled it would remember the old config (or so it seemed to me at least)

On my side I still have the problem that I need potentially multiple power cycles with following RESTART and FIRMWARE_RESTART to have the display properly initiated. The ugly thing is that failing to initialize the display properly can lead to

• a garbled screen
• "ST7920Emulator ready"
• a black screen with only the firmware title So when setting up a new display it can be difficult to distinguish between wrong configuration and a failed display initialization.

My recommendation when doing this: setup the new config --> powercycle the board --> sudo service klipper restart --> FIRMWARE_RESTART

Maybe paranoid but I had my fingers burned and spent some hours screaming at the stupid display

I would need to understand how you envision that I use that pinout to fix my problem, which is on a GTR board. My [display] section is identical to yours. My aliases are specific to my board, but if I grasp your intent, it was to be sure that I have the display setting correct. Check.

Now I have fully powered down multiple times. Everything off and cold. It is always the same - "ST7920Emulator ready" By board, I am assuming you mean mainboard and not the TFT35, which has its own mcu board. I could boot, run klipper restart, then firmware restart, and see if that changes anything? If so, well nothing happened. this is all while still running 1.2. Did I misunderstand?

[teeminus]

https://github.com/teeminus/NoTouchScreenFirmware/issues/12#issue-806941098

If you can't get the v1.2 firmware to work, please try the v1.1 firmware. This has been reported working by @Sineos: #2 (comment)

Originally posted by @teeminus in #5 (comment)

So which version - bfgd07a7? Not sure how to revert back to that from the main easily if yo have a suggestion how to do so please let me know.

I think the bfgd07a7 commit was in a branch that no longer exists. But that branch was based on the V1.1 release, so you can simply download that release from the releases page.

If you tests your screen with Marlin, please test the original BTT firmware for the screen as well.

[bakaufman]

#12 (comment)

If you can't get the v1.2 firmware to work, please try the v1.1 firmware. This has been reported working by @Sineos: #2 (comment) Originally posted by @teeminus in #5 (comment) So which version - bfgd07a7? Not sure how to revert back to that from the main easily if yo have a suggestion how to do so please let me know.

I think the bfgd07a7 commit was in a branch that no longer exists. But that branch was based on the V1.1 release, so you can simply download that release from the releases page.

If you tests your screen with Marlin, please test the original BTT firmware for the screen as well.

Much to my embarrassment, I cannot find binaries or source of V1.1. There wasn't a fork, only tags in history. I haven't often gone back to prior revisions of anything in Github, so I might just lack the knowledge of where to go. I apologize, but can you point me in the correct direction?

[teeminus]

The releases can be found here: https://github.com/teeminus/NoTouchScreenFirmware/releases

In the meantime there has been an other user with TFTv3E3 display (and a SKR V1.4 mainboard) who had problems with his display. In the end it was just the config but it might be worth a look: https://github.com/teeminus/NoTouchScreenFirmware/issues/13

[bakaufman]

With the v1.1 bin I get notouchfirmware v1.1 only at the top with klipper restart then klipper firmware restart.

[bakaufman]

The releases can be found here: https://github.com/teeminus/NoTouchScreenFirmware/releases

In the meantime there has been an other user with TFTv3E3 display (and a SKR V1.4 mainboard) who had problems with his display. In the end it was just the config but it might be worth a look: #13

My [display] is the same as the recommended settings in the thread

[Sineos]

I can only confirm that v1.2 is working on my SKR1.4 with the above settings.

The only thing is that it can be very touchy to properly initialize. Sometimes multiple full power cycles of the printer board combined with FIRMWARE_RESTART might be needed to come up properly.

[bakaufman]

If you tests your screen with Marlin, please test the original BTT firmware for the screen as well.

I no longer have marlin on the printer. what I was saying was that when I had marlin and the btt firmware on the screen, the current cable positions and orientation worked.

[teeminus]

As a last test you could test the V1.0 release. This is the closest this firmware has been to the original BTT firmware.

[teeminus]

After looking through the code it seems like there is not much difference between the TFT35v3 and the E3 version. The only difference is that the E3 version has (one or more) WS2812. But regarding the Marlin mode, the screens are identical. So besides the filename of the binaries the firmware for both screens are identical (the filename is hardcoded in the binary though).

You reported that the ST7920Emulator ready is shown on the screen so the TFT driver and the emulator is working properly. I own a "normal" TFT35v3 which is working fine that's why I think the firmware is okay. So for some reason either the data from klipper is not received or processed (which I doubt as others would have reported that as well) or not send to the display in the first place.

Possible reasons for that might (without judging oder weighting):

• hardware damages (TFT, GTR or cabeling (could be a broken wire))
• misplaced connectors
• incorrect klipper config on the PC side (like incorrect pins)
• incorrect klipper firmware binary (like incorrect configuration during compiling)

[bakaufman]

swapping exp 1 and 2 doesn't work (black screen). there is nothing wrong with the connections - validated by using Marlin. There is a difference in the two boards in that E3 can run in E3/creality format, so I tried the regular board version (v1.2) and it didn't work. I tried E3 v1.0, v1.1, and v1.2. I give up.

[teeminus]

swapping exp 1 and 2 doesn't work That's because only one of the two connectors has a power line.

I give up. I am sorry to hear that. I hoped we could work out the issue.

Are you sure that the firmware for the GTR is compiled correctly? By the way, does the klipper log has some infos that might be useful?

[bakaufman]

klippy.log What I think I meant to communicate is that I don't see a path forward. If the klippy.log helps, here it is. What is your definition of GTR being compiled correctly? I installed the fluiddpi image, used kiauh to add klipper screen (touch screen), updated my config. Kept everything updated using autoupdater in fluidd. Let me know what your test is for correct and I'll certainly run it!

[teeminus]

I compiled the klipper firmware for my SKR Pro myself. Had a look at that again yesterday but you can only select the MCU family in the config tool but not the specific board as I thought.

Thanks for the log file. I saw nothing suspicious on first sight but I will compare it to my klipper log and see if I find something odd.

[bakaufman]

Thank you!

[teeminus]

I havn't made any progress on the logs yet but today I got a weird behaviour of my TFT35v3. I started my printer as usual but the "ST7920Emulator ready" text did not disappear. I had to restart the firmware of my controll board multiple times to get actual screen content displayed.

Anyways: I currently work on readding the CS functionality which I initially removed because I thought it might be not needed. After thinking about your issue I thought I might readd that feature to be sure that the display parses only data ment to be send to it (in case the SPI bus is used for something else as well). As a first step I added some visual indicator to the display if the startup sequence has been successfully executed. I also added a visual indicator if SPI data for the display has been received. I pushed the WIP code to the following branch: https://github.com/teeminus/NoTouchScreenFirmware/tree/readd_cs_pin

If you recompile the firmware from that branch you will see a horizontal line below the "NoTouchFw V1.2" text. If you see that, the screen and the SPI has been initialized and the processing loop has been entered. For each received SPI byte a pixel in the top 7 rows if the display will be filled (and if the counter wraps the color changes from white to black and so on) so you've got a live view if SPI data is received. When I was in that weird mode mentioned above I rotated the knob and the SPI indicator changed, so I think there was something wrong with the emulator.

If you try the WIP firmware and you see both the horizontal line and the SPI indicator we know that the cabling and the config is correct and the bug has to be in the emulator. I hope I can reproduce the faulty behaviour and investigate that issue further.

[Sineos]

I started my printer as usual but the "ST7920Emulator ready" text did not disappear. I had to restart the firmware of my controll board multiple times to get actual screen content displayed.

This is more or less default on my side. I have seen everything from garbled screen over header only to "ST7920Emulator ready" and usually I need to reset the board followed by a firmware_restart to make it come up correctly.

Side note: I switched from TMC5160 driver (SPI) to TMC2209 (UART) yesterday and it seems the display initializes more stable. This may support your SPI theory.

[teeminus]

I added the CS flow control back to the firmware (already pushed to the branch). I tested cold boot, restart of klipper and klipper firmware in various orders and it seems to work much better now. I hope this fixes your issues.

[Sineos]

I added the CS flow control back to the firmware (already pushed to the branch). I tested cold boot, restart of klipper and klipper firmware in various orders and it seems to work much better now. I hope this fixes your issues.

Works for me and on first tests the display came up nicely. 👍

[teeminus]

So I would say the performance improved for you as well 😄

[teeminus]

What do you think about the SPI data activity indicator? I made that a compile time switch which is active by default but I am not sure if I should add that as a default value to the next release. On the one hand it is great for debugging but on the other hand it reduces the overall performance a little.

[Sineos]

Hmpf, I have to revert my initial enthusiasm: Now I just needed 3 cold boots to get the display back. Even multiple resets followed by firmware restart did not bring it back

What do you think about the SPI data activity indicator?

Actually I would assume it brings a lot of support questions. My first reaction was like "why is my display borked at the top now?" until I realized it was meant to be the SPI activity indicator.

Basically it works nicely. You can see the activity, e.g. while heating up the extruder or while turning the encoder but apart from debug purposes I would keep it disabled.

In your commit message you wrote CS (^= ST7920 enable). Does this mean I have to pull up the pin in my config?

[teeminus]

In your commit message you wrote CS (^= ST7920 enable). Does this mean I have to pull up the pin in my config?

No, there is no pullup required. The CS pin acts like an enable signal for the ST7920. Normally you would expect CS go from HIGH to LOW when a SPI slave is selected. But for the ST7920 this logic is inverted as the ST7920 has an enable pin with positive logic.

Hmpf, I have to revert my initial enthusiasm: Now I just needed 3 cold boots to get the display back. Even multiple resets followed by firmware restart did not bring it back

Hmm, that's strange. I would have expected that the display works much better now. For debug purposes I dumped all received data over the UART of the display to see if the data send by klipper is received correctly. Thats when I noticed, that in some cases the received data is complete garbage. And here comes to CS into play. When the CS (= ST7920 enable) has a falling edge, the SPI bus is reset and reinitialized on a rising edge. My guess on the garbage display data was, that the state of the SPI bus might be off by a few SPI clocks, meaning that two consecutive bytes overlap in the SPI input buffer (exampe: bitstream 0b0000111111110000 would result in 0b11111111 when the SPI clock is off by 4). This can only be fixed by reinitializing the SPI bus of the TFT.

But that is only a theory. And I have no idea how this could happen.

Do you have a stable way of reproducing the error? I thought about either reinitializing the SPI bus after a specific time of inactivity or by pressing the knob for a few seconds.

[Sineos]

Do you have a stable way of reproducing the error? I thought about either reinitializing the SPI bus after a specific time of inactivity or by pressing the knob for a few seconds.

It happens only when

• the klipper service is restated and/or
• the firmware is restarted and/or
• the board is reset via hardware button and/or
• the printer board is cold booted

So for me it seems that the initial startup of the display is critical. Maybe a timing issue? Once the display is up and running, I had no single failure. Not even after hours / days of inactivity.

My two most reliable ways are:

1. Cold boot the SKR board and then restart klipper service (most reliable way)
2. Reset the board via hardware reset and issue a firmware_restart

[teeminus]

I am running klipper on an Odroid U3 and it takes ~22sec from cold boot to screen update. I tried multiple cold boots and was not able to get the display into a faulty state. How long does your setup take to boot?

Then I tried:

1. restarting the linux klipper service
2. restarted klipper by echo "RESTART" >> /tmp/printer
3. restarted firmware by echo "FIRMWARE_RESTART" >> /tmp/printer
4. unplugged the TFT
5. pressed the hardware reset
6. power cycled the SKR without powercycling the Odroid

The only time I got the display to hang when I issued 2. and 3. to close to each other (I issued 3. before the display had been initialized by 2.). But the I could exit that state by either using 2. or 3 (I think 1 should have worked too).

Regarding the timing issue: You could try moving up the SPI_Slave init code from line 132 to eg. line 100 (prior the LCD_Init code). The SPI queue should be big enough to store any received data until the rest of the initialization has been done.

P.S.: For the records: I use Klipper versions v0.9.1-139-ga5ebe582 on the SKR and v0.9.1-140-ge68cf08d on the Odroid.

[Sineos]

Firmware and Klipper version both: v0.9.1-219-g03b62ca0

With cold-boot I was always referring to power-cycling the printer-mcu-board. I virtually never restart my Pi3B with Octoprint. Sorry for not being more precise.

No1, No2, No3, No5 and No6 are for me sources of failure. Sometimes more sometimes less.

You could try moving up the SPI_Slave init code from line 132 to eg. line 100 (prior the LCD_Init code).

Will try and report back

[teeminus]

I forgot to mention that when my TFT is hanging, the SPI data indidactor does not change when I rotate or click the knob. So I think that in my case it's rather klipper not communicating with the display than the display actually hanging. Does anything change on your display when it hangs and you use the knob?

And when I issue a FIRMWARE_RESTART, the TFT turns off and restarts so I think klipper performs a hardware reset of the display by triggering the reset line.

I also updated to the last klipper version (v0.9.1-229-g319c36df) but the behaviour has not changed.

By the way, thank you for debugging this problem with me 😄

[Sineos]

https://drive.google.com/file/d/17KdFRhUaWo0_mE9XPh184C3NUSflZjSd/view?usp=sharing

Moving the

 // Init slave SPI
  CIRCULAR_QUEUE spiQueue;
  SPI_Slave(&spiQueue);

before LCD_Init did not solve the issue. After 2 firmware_restart I ended up with a garbled screen (see link above) but apparently SPI traffic continued to work.

What I noticed as well is that no combination of firmware_restart, restart or service klipper restart would restore it (tried about 15 times). A power-cycling of the SKR board followed by a firmware_restart brought it back immediately.

By the way, thank you for debugging this problem with me 😄

Well, thank YOU for supporting this 😄

[teeminus]

The garbled screen is cause by corrupted data. Thats data from the buildin ST7920 font. Seems liks the emulator got a sequence that caused him to think that chars from this font shall be drawn to the screen.

Does your screen restart completely by firmware_restart? My screen turns black for a split second and then boots again.

I will try adding SPI re-init when long pressing the knob. Maybe that helps reducing the number of restarts you have to perform before the screen works 😉

[Sineos]

When in "garbled mode" any restart (firmware_restart, restart or service klipper restart) would just shuffle the garbage

firmware_restart OK to garbled https://drive.google.com/file/d/1vJ-1tOMv2J_MLHMQDyvbWSgr8-uAIEKt/view?usp=sharing

firmware_restart garbled to garbled https://drive.google.com/file/d/1HmHOqPgWjyOp9Mhc-99lse4_Bp-UyV9d/view?usp=sharing

[teeminus]

Your screen seems to be not resetted on firmware_restart, mine is (I will make a video of that tomorrow). That causes the problems as the SPI data gets corrupted.

And it seems like that the CS pin has a contant high level, otherwise the SPI would be reinitialized.

[Sineos]

I tried to make a more systematic approach now and compared

• The BTT SKR1.4 Pin-Out - https://github.com/bigtreetech/BIGTREETECH-SKR-V1.3/blob/master/BTT%20SKR%20V1.4/Hardware/BTT%20SKR%20V1.4PIN.pdf
• The BTT Schematic - https://github.com/bigtreetech/BIGTREETECH-SKR-V1.3/blob/master/BTT%20SKR%20V1.4/Hardware/BTT%20SKR%20V1.4-SCH.pdf
• The LPC Data Sheet - https://www.nxp.com/docs/en/data-sheet/LPC1769_68_67_66_65_64_63.pdf
• The TFT35-E Schematic - https://github.com/bigtreetech/BTT-TFT35-E3-V3.0/blob/master/Hardware/BTT%20TFT35-E3%20V3.0PIN.pdf

For me it looks quite sensible. Do you see anything amiss?

Header	BTT Pin-Out	BTT Schematic	LPC Datasheet	TFT35-E3 Schematic	Klipper
EXP1
EXP1_1	P1_30	P1_30	I/O	Beep	output_pin beeper
EXP1_2	P0_28	P0_28	I/O, SCL0 - I2C0 clock input/output	BTN Click	click_pin
EXP1_3	P1_18	P1_18	I/O	LCD-EN	sid_pin
EXP1_4	P1_19	P1_19	I/O	LCD-CS	cs_pin
EXP1_5	P1_20	P1_20	I/O	LCD-D4	sclk_pin
EXP1_6	P1_21	P1_21	I/O	LCD-D5
EXP1_7	P1_22	P1_22	I/O	LCD-D6
EXP1_8	P1_23	P1_23	I/O	LCD-D7
EXP1_9	GND	GND		GND
EXP1_10	VCC	VCC		VCC
EXP2
EXP2_1	P0_17	MISO0	MISO0 - Master In Slave Out for SSP0, MISO - Master In Slave Out for SPI	SD-MISO
EXP2_2	P0_15	SCK0	SCK0 - Serial clock for SSP0, SCK - Serial clock for SPI	SD-CLK
EXP2_3	P3_26	P3_26	I/O, PWM1[3] - Pulse Width Modulator 1, output	ENC-A	encoder_pins
EXP2_4	P0_16	SSEL0	SSEL0 - Slave Select for SSP0, SSEL - Slave Select for SPI	SD-CS
EXP2_5	P3_25	P3_25	I/O, PWM1[2] - Pulse Width Modulator 1, output 2	ENC-B	encoder_pins
EXP2_6	P0_18	MOSI0	MOSI0 - Master Out Slave In for SSP0 MOSI - Master Out Slave In for SPI.	SD-MOSI
EXP2_7	P1_31	P1_31	I/O, SCK1 - Serial Clock for SSP1	SD-DET
EXP2_8	Reset	Reset		Reset
EXP2_9	GND	GND		GND
EXP2_10	NC	NC		NC