BTT GTR and TFT35v3 E3 not working #5

bakaufman · 2021-02-09T14:52:48Z

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 · 2021-02-09T14:58:59Z

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 · 2021-02-09T15:01:07Z

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 · 2021-02-09T15:09:06Z

Have you restarted Klipper after installing the firmware?

bakaufman · 2021-02-09T15:38:34Z

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 · 2021-02-09T15:45:40Z

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 · 2021-02-09T16:26:47Z

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 · 2021-02-09T16:35:37Z

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 (#5 (comment)) the issue is most likely in the klipper config.

bakaufman · 2021-02-09T16:56:27Z

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 · 2021-02-09T17:22:14Z

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 · 2021-02-09T17:33:28Z

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

teeminus · 2021-02-09T18:02:09Z

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 · 2021-02-09T18:24:03Z

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 · 2021-02-09T19:18:41Z

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

bakaufman · 2021-02-09T19:30:29Z

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 · 2021-02-09T22:38:45Z

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 · 2021-02-10T06:20:21Z

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)

Sineos · 2021-02-10T06:51:39Z

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 · 2021-02-12T04:19:41Z

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 · 2021-02-12T04:28:11Z

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 · 2021-02-12T05:27:27Z

#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.

bakaufman · 2021-02-12T14:09:36Z

#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 · 2021-02-12T14:13:31Z

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

bakaufman · 2021-02-12T15:06:10Z

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

bakaufman · 2021-02-12T15:09:15Z

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 · 2021-02-12T15:20:00Z

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 · 2021-02-12T23:51:58Z

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 · 2021-02-13T09:20:32Z

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 · 2021-02-13T16:27:09Z

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 · 2021-02-13T16:37:22Z

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.

Sineos · 2021-02-16T19:07:58Z

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 · 2021-02-16T19:31:50Z

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 · 2021-02-16T20:15:04Z

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 · 2021-02-16T20:37:37Z

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 · 2021-02-17T08:28:35Z

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

teeminus · 2021-02-17T09:33:21Z

Looks okay so far.

I made a video of my display when firmware_restart is issued (sorry for the shaky hands and the f*cked up orientation): https://www.youtube.com/watch?v=-EGkBiCLdRU
As you can see the display switches from "Ready" to displaying the current coordincates, then resets and waits for new data until klipper has restarted. The first part is identical to your screen but on your screen no reset occures and that causes the spi bit shift.
BUT: When I disconnect the EXP2 connector my screen won't work anymore after firmware_restart. Do you have the EXP2 connector plugged in?

I played a bit with the SPI polarity (CPOL and CHPA) but that did not improve the behaviour.

I pushed a new commit to the dev branch which allows resetting of the SPI peripherals of the display if the knob button is pressed for at least 5 seconds. Once you release the button, the screen will turn off and on again to indicate that the SPI has restarted. Afterwards firmware_restart will bring it back to live (at least for me when the EXP2 connection is missing).

I also looked through the klipper firmware source and noticed, that the firmware can be restarted by sending a specific USB command. Unfortunatelly this feature is only available for the LPC176X platform when the CONFIG_SMOOTHIEWARE_BOOTLOADER flag is set by make menuconfig.

Sineos · 2021-02-17T13:14:08Z

Do you have the EXP2 connector plugged in?

Yes, it is plugged

As you can see the display switches from "Ready" to displaying the current coordincates, then resets and waits for new data until klipper has restarted.

Quite obvious. This step over the reset is missing on my side. From the pin assignment it should be correct, so is there anything I can do from my side?

I pushed a new commit to the dev branch which allows resetting of the SPI peripherals of the display if the knob button is pressed for at least 5 seconds. Once you release the button, the screen will turn off and on again to indicate that the SPI has restarted. Afterwards firmware_restart will bring it back to live (at least for me when the EXP2 connection is missing).

Seems to work well on first tests. I can revive a garbled display by resetting it via "knob long press" and firmware_restart

teeminus · 2021-02-17T13:27:14Z

Quite obvious. This step over the reset is missing on my side. From the pin assignment it should be correct, so is there anything I can do from my side?

Unfortunatelly I have no more ideas what to try next. You try setting that CONFIG_SMOOTHIEWARE_BOOTLOADER by recompiling the klipper firmware.

But I honestly have no clue that this flag is about and what the smoothieware bootloader does differently. And if it will even run on the SKR board or in the worst case even damage the board.

I am still curious why the original BTT firmware seems to behave different on this topic. As far as I can see now the relevant parts of their code have been added to this firmware and it does behave differently. Still may be a timing issue as this firmware seems to boot a lot fast but besides that there should be no major differences.

Seems to work well on first tests. I can revive a garbled display by resetting it via "knob long press" and firmware_restart

Well, at least that's something...

bakaufman · 2021-02-17T17:07:59Z

Is there a way to branch this discussion. As the OP, I have lost the thread.

Sineos · 2021-02-17T19:36:31Z

Is there a way to branch this discussion. As the OP, I have lost the thread.

My apologies for having hijacked your issue.

To compensate, I have checked the schematics and pin-out of the GTR and following config should be correct:

[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>

[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

[output_pin beeper]
pin: EXP1_1

The only thing, I found strange during this check is:

But as long as the cable orientation is correct this should not matter as you are accessing the raw pin numbers and the EXPx_y is only an alias.

teeminus · 2021-02-18T08:53:20Z

Is there a way to branch this discussion. As the OP, I have lost the thread.

We could move to Discussions

The only thing, I found strange during this check is:

Thats a bit crude but they fix that by rotating the cable. Strange but it works.

On thing that really bugs be is the following. I hooked up a logic analyzer to the display data bus to see if the SPI config is correct:

The signals are (top to bottom): Clock, data, CS/Enable

From that image I would have expected that the SPI data is sampled on the rising edge of clock signal (falling edge would work as well). The idle level of the clock signal is obviously low. Speaking from the SPI config this would mean CPOL=0 and CPHA=0/1 (CPOL=clock polarity, CPHA=clock phase):

CPHA basically defines if the SPI data is sampled on the first or the second edge of the clock signal. BTT initializes the SPI bus with CPOL=CPHA=1 meaning an idle high level of the clock signal is expected and data is sampled on a rising edge of the clock signal. But from my opinion this is wrong and I don't know why this has ever worked. Thats seems to be the reason why the display firmware no longer works after klipper has been restarted. But that does not explain why it works sometimes but not always.

--- Break here from the previous low level SPI topic ---
I added an other display indicator which shows how often the SPI bus is (re-)initialised. That happens when the CS pin has a rising edge. From my experiments I saw that this indicator changes only once - when the display is started.During operation (and restart of klipper) that does not happen. Thats why the SPI (which should not be working in the first place but does anyways) stops working after klipper has been restarted. I added a small pulse to the CS pin in the klipper firmware and suddenly the firmware works even when klipper is restarted and no hardware reset is performed by the restart. But when I added this to the klipper firmware I had to change the SPI config to the settings I would have expected from the logic anaylzer image.
So anyways, fixing one problems causes an other. Adding the reset feature to klipper might cause a lot of BTT screens not to work properly when the firmware is reset but no hardware reset is triggered.

teeminus · 2021-02-18T09:32:53Z

NOPE 😄 😄 😄

I recompiled the original BTT firmware and tested it with my klipper fix. And it works even when the display is not reset on firmware_restart. Well, of course there is the incomplete emulator which makes the screen not look as nice as this firmware but at least the SPI bus is initialised correctly after the CS pin has been changed. I pushed the required firmware changes to the dev branch. This should not change the behaviour of your display, it should work until firmware_restart breaks the SPI bus.

I joined the klipper discord to discuss this there. Maybe the fix will be added to klipper so we finally ge rid of that issue. In case you want to try the klipper fix yourself I can post the required code changes here.

bakaufman · 2021-02-18T14:14:40Z

First - I am glad progress is getting made. I just can't tell what was relevant to my issue.

Second - I just installed the ADXL345 yesterday and after hours of trouble shooting we figured out that the SPI0 bus was being used by another touch screen. We assigned the ADXL345 to SPI1 but it didn't work, and I had to comment out the other display in config.txt to reclaim the SPI0 and everything started working with Klipper and ADXL345 (so far). So could the problem be SPI in my case as well? Sorry if I haven't captured everything you both have talked about - it was a lot (which is good).

bakaufman · 2021-02-18T14:19:22Z

Is there a way to branch this discussion. As the OP, I have lost the thread.

My apologies for having hijacked your issue.

To compensate, I have checked the schematics and pin-out of the GTR and following config should be correct:
[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>

[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

[output_pin beeper]
pin: EXP1_1
The only thing, I found strange during this check is:

But as long as the cable orientation is correct this should not matter as you are accessing the raw pin numbers and the EXPx_y is only an alias.

I had the same settings. I am missing the point on the EXPx_y though?

teeminus · 2021-02-18T14:30:17Z

Second - I just installed the ADXL345 yesterday and after hours of trouble shooting we figured out that the SPI0 bus was being used by another touch screen. We assigned the ADXL345 to SPI1 but it didn't work, and I had to comment out the other display in config.txt to reclaim the SPI0 and everything started working with Klipper and ADXL345 (so far). So could the problem be SPI in my case as well? Sorry if I haven't captured everything you both have talked about - it was a lot (which is good).

It could be a problem if the display pins are used by SPI0. The klipper firmware does not use a hardware SPI but bitbangs the data by using the IO pins directly. If these pins are used elsewhere, this could cause your problems.

I had the same settings. I am missing the point on the EXPx_y though?

The pins on the mainboard are mirrored. E.g. EXP1.1 is VCC_5V but in the klipper config this is EXP1.10. If you would connect the pins directly without the twisted cables this would not work. But the screen cables are all twisted so that all pins are connected correctly.

Sineos · 2021-02-19T06:59:21Z

Second - I just installed the ADXL345 yesterday and after hours of trouble shooting we figured out that the SPI0 bus was being used by another touch screen. We assigned the ADXL345 to SPI1 but it didn't work, and I had to comment out the other display in config.txt to reclaim the SPI0 and everything started working with Klipper and ADXL345 (so far). So could the problem be SPI in my case as well? Sorry if I haven't captured everything you both have talked about - it was a lot (which is good).

It could be a problem if the display pins are used by SPI0. The klipper firmware does not use a hardware SPI but bitbangs the data by using the IO pins directly. If these pins are used elsewhere, this could cause your problems.

Quoting a statement from Kevin over at Klipper repo:

The problem with the adxl345 is that if the CS pin is low, the chip itself treats the MISO/MOSI/CLK lines as an I2C bus. In some situations, a command to another spi device could be seen as an i2c request and the adxl345 would respond in i2c mode - causing corruption of messages.

Sineos · 2021-02-19T07:01:35Z

I joined the klipper discord to discuss this there. Maybe the fix will be added to klipper so we finally ge rid of that issue. In case you want to try the klipper fix yourself I can post the required code changes here.

Maybe the best approach would be to open a PR at Klipper to have Kevin a look at it.
If you want I will make the relevant changes to the klipper src to verify your findings.

Amazing job. Thanks for digging in so deeply

teeminus · 2021-02-19T07:10:33Z

Maybe the best approach would be to open a PR at Klipper to have Kevin a look at it.
If you want I will make the relevant changes to the klipper src to verify your findings.

I already spoke to Kevin (on discord) about my finding and my suggested fix. It would have been a low level fix in the MCU firmware but Kevin does not like the approach as he wants to keep the MCU code as simple as possible. I can totally understand this and as he suggested to fix this problem in the python code, that's what I am currently looking at 😆 I will keep you updated once I got it working.

Amazing job. Thanks for digging in so deeply

I do what I can 😄

bakaufman · 2021-02-21T03:23:29Z

Pretty cool - keep us up to date please

…

On Feb 19, 2021, at 2:10 AM, teeminus ***@***.***> wrote: Maybe the best approach would be to open a PR at Klipper to have Kevin a look at it. If you want I will make the relevant changes to the klipper src to verify your findings. I already spoke to Kevin (on discord) about my finding and my suggested fix. It would have been a low level fix in the MCU firmware but Kevin does not like the approach as he wants to keep the MCU code as simple as possible. I can totally understand this and as he suggested to fix this problem in the python code, that's what I am currently looking at 😆 I will keep you updated once I got it working. Amazing job. Thanks for digging in so deeply I do what I can 😄 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHTLR2DNEVREYYAIEHPOLFTS7YFH7ANCNFSM4XLEM7KA>.

teeminus · 2021-02-25T06:53:39Z

It seems like we found a solution for this problem. Once the fix have been merged to Klipper I will create a new release of this firmware and a short writeup on how to setup Klipper correctly.

bakaufman · 2021-02-25T18:23:28Z

thanks - I have not been able to circle back to this but would love to see it working. Any sense of whether the TFT side will ever see the light of day?

teeminus · 2021-02-25T18:42:18Z

thanks - I have not been able to circle back to this but would love to see it working. Any sense of whether the TFT side will ever see the light of day?

I'm sorry, I don't understand your question.

bakaufman · 2021-02-25T18:44:06Z

I am very sorry for being unclear. You have indicated that you have the no touch (marlin side) working. Is there the potential to get the touch side working in the future?

teeminus · 2021-02-25T18:51:44Z

You mean the "other" mode with the touch button which uses the uart to communicate with the printer? No, I won't add that to this firmware. Mostly because I want to keep this firmware as simple as possible - and because I think the original BTT firmware is to complex and bloated.

And I am not sure if this touch mode will work with Klipper.

bakaufman · 2021-02-25T20:03:44Z

Thank you for all that you do!

teeminus · 2021-03-02T08:23:45Z

The PR for Klipper has been merged. I created a new release for this firmware and updated the wiki to show how to migrate to the new Klipper display driver. Please checkout the release notes as well.

teeminus · 2021-05-02T14:38:05Z

@bakaufman Could you please test again with the latest klipper and tft firmware?

bakaufman · 2021-05-02T15:11:07Z

I’ll try to this week. It has been moved to a different printer.

…

On May 2, 2021, at 10:38 AM, teeminus ***@***.***> wrote: @bakaufman <https://github.com/bakaufman> Could you please test again with the latest klipper and tft firmware? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHTLR2CQOPJGVHUFO67GV4TTLVPVVANCNFSM4XLEM7KA>.

baracoder mentioned this issue Feb 20, 2021

BTT SKR Mini 2.0 and TFT35-e3 v3.0 not working #20

Closed

teeminus closed this as not planned Won't fix, can't repro, duplicate, stale Jun 1, 2022

BTT GTR and TFT35v3 E3 not working #5

BTT GTR and TFT35v3 E3 not working #5

Comments

bakaufman commented Feb 9, 2021

teeminus commented Feb 9, 2021

bakaufman commented Feb 9, 2021 • edited Loading

teeminus commented Feb 9, 2021

bakaufman commented Feb 9, 2021

teeminus commented Feb 9, 2021

bakaufman commented Feb 9, 2021

teeminus commented Feb 9, 2021

bakaufman commented Feb 9, 2021

bakaufman commented Feb 9, 2021

bakaufman commented Feb 9, 2021

teeminus commented Feb 9, 2021

bakaufman commented Feb 9, 2021

bakaufman commented Feb 9, 2021

bakaufman commented Feb 9, 2021 • edited Loading

bakaufman commented Feb 9, 2021 • edited Loading

teeminus commented Feb 10, 2021 • edited Loading

Sineos commented Feb 10, 2021

bakaufman commented Feb 12, 2021

bakaufman commented Feb 12, 2021

teeminus commented Feb 12, 2021

bakaufman commented Feb 12, 2021

teeminus commented Feb 12, 2021

bakaufman commented Feb 12, 2021

bakaufman commented Feb 12, 2021

Sineos commented Feb 12, 2021

bakaufman commented Feb 12, 2021

teeminus commented Feb 13, 2021

teeminus commented Feb 13, 2021

bakaufman commented Feb 13, 2021

Sineos commented Feb 16, 2021

teeminus commented Feb 16, 2021 • edited Loading

Sineos commented Feb 16, 2021

teeminus commented Feb 16, 2021

Sineos commented Feb 17, 2021

teeminus commented Feb 17, 2021

Sineos commented Feb 17, 2021

teeminus commented Feb 17, 2021

bakaufman commented Feb 17, 2021

Sineos commented Feb 17, 2021

teeminus commented Feb 18, 2021

teeminus commented Feb 18, 2021 • edited Loading

bakaufman commented Feb 18, 2021

bakaufman commented Feb 18, 2021

teeminus commented Feb 18, 2021

Sineos commented Feb 19, 2021

Sineos commented Feb 19, 2021

teeminus commented Feb 19, 2021

bakaufman commented Feb 21, 2021 via email

teeminus commented Feb 25, 2021

bakaufman commented Feb 25, 2021

teeminus commented Feb 25, 2021

bakaufman commented Feb 25, 2021

teeminus commented Feb 25, 2021

bakaufman commented Feb 25, 2021

teeminus commented Mar 2, 2021

teeminus commented May 2, 2021

bakaufman commented May 2, 2021 via email

bakaufman commented Feb 9, 2021 •

edited

Loading

bakaufman commented Feb 9, 2021 •

edited

Loading

bakaufman commented Feb 9, 2021 •

edited

Loading

teeminus commented Feb 10, 2021 •

edited

Loading

teeminus commented Feb 16, 2021 •

edited

Loading

teeminus commented Feb 18, 2021 •

edited

Loading