search

teeminus / NoTouchScreenFirmware

Stripped down version of BIGTREETECH-TouchScreenFirmware which only supports ST7920 emulation (Marlin Mode)
GNU General Public License v3.0
149 stars 37 forks source link

BTT GTR and TFT35v3 E3 not working #5

Closed bakaufman closed 2 years ago

bakaufman commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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. image 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 commented 3 years ago

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

Sineos commented 3 years ago

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: grafik

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 commented 3 years ago

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: image 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): image

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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: grafik

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Pretty cool - keep us up to date please

On Feb 19, 2021, at 2:10 AM, teeminus notifications@github.com 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 https://github.com/teeminus/NoTouchScreenFirmware/issues/5#issuecomment-781880672, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHTLR2DNEVREYYAIEHPOLFTS7YFH7ANCNFSM4XLEM7KA.

teeminus commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Thank you for all that you do!

teeminus commented 3 years ago

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 commented 3 years ago

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

bakaufman commented 3 years ago

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 https://github.com/teeminus/NoTouchScreenFirmware/issues/5#issuecomment-830819481, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHTLR2CQOPJGVHUFO67GV4TTLVPVVANCNFSM4XLEM7KA.