Toubleshooting a BTT TFT35 that will not connect in TFT mode, only Marlin mode

Mostly Printed 3D Printer - MP3DP Troubleshooting
1

This is a second post in a series where I’m working to troubleshoot and repair some damaged/suspect boards that have come into my possession.

I have a pair of BTT TFT35s that have an identical symptom. These power on OK, and can select Marlin mode and Touch mode. They work fine in Marlin mode, but do not work in Touch mode. Touch mode comes up fine and the GUI is repsomsive, but they throw an error that there is no printer connected. All settings are correct on both boards.

I have a known good SKR Pro 1.2 and known good TFT35, both of which were purchased from Ryan for my (still stalled) Repeat printer build. I tested each of the two suspect TFT35s with my known good SKR Pro, and the symptoms are repeatable. I also proved with the known good TFT35 that my SKR Pro works fine in Touch mode.

In researching this, there are apparently at least two reasons for this.

There are reports I saw that at least one batch of TFT35s had this issue from the factory, with either defective connectors and/or shorted TX/RX pins on the board. I very carefully inspected both of the boards that I have, and could not see an obvious defect.

I also rung out the pins on the connector to the SMT pins on the board, and confirmed that there is continuity to each pin. So, this isn’t a solder, short, or connector problem at least on these two boards.

Further reading about the TFT35s, there appear to be a fair number of users who blow out the UARTs on the touch side of these.

I did a test with a serial adapter set to 250000 baud, and was not able to get any data into either of the two suspect TFT35s that I have. I’m pretty sure this is the issue with these two systems- they are deaf from a blown UART.

I didn’t want to consider replacing the microcontroller on these, so I decided to build a test version of the BTT firmware that changes the define for the touch UART to be the one labeled UART3 on the board. This is not normally used in most system setups.

Initial testing looks promising- having flashed this version of the firmware, my bench test setup lets me send data to the TFT35 and it seems happy.

My next step will be hooking this TFT up to an SKR Pro and testing that the modified TFT35 works with the alternate UART configuration. This will require me to slightly rewire the connections as I plan to keep +/- 5V and RESET on the normal connector, but move TX/RX from there to the UART3 position.

I’m going to pause here for a bit as I also have a copule of damaged/suspect SKR Pro 1.2s that I’m also working on fixing. One of those SKR Pros may, in fact, have been a companion to one of the misbehaving TFT35s. That SKR pro appears to have a blown UART on its’ TFT port. Sounds fishy, right?

Since I don’t want to blow up my known good SKR Pro, and I want to be certain about the other suspect SKR pro, I’m going to focus on trying to troubleshoot that board next.

If this turns out to be a viable way to fix a TFT35 with this problem, I’ll post some additional notes here as well as the binary that I built with the swapped UART definition.

I’m curious if anyone else in the V1 community has seen this issue with a BTT TFT35 (or one of the clones)?

2 Likes
2

I haven’t seen that myself. And I don’t remember seeing that in the forums. But there are a lot of good people who don’t have your knack. So it may have frustrated some people without us figuring it out.

I made a little script to open a uart on a USB FTDI and pretend to be Marlin for the TFT. It sounds like you made something similar.

3

It would seem you are not the first to try this proposed fix -

  1. Nuclear option
  2. Undo the RX and TX wires from the JST cable with a small flat blade screwdriver.
  3. Place the RX wire from the board into the TX of the UART3 connection (Far left with EXP connections as top)
  4. Place the TX wire from the board into the RX of the UART3 connection (middle)
  5. Plug JST connection back into the RS232 port at upper right, now missing two wires.
    1. looks like RST>BLANK>BLANK>GND>5v
  6. Plug the JST connector (or bare wire to test, do not short this out!!!) into the UART3 port.
  7. Flash the firmware from here WARNING - GD controller chips ONLY to the TFT35
    1. Format SD card
    2. Place BIGTREEGD_TFT35_V3.0_E3.27.x.bin file on SD
    3. open config.ini file and CHANGE line 101 to be:
    4. 101 serial_port:P1:6 P2:6 P3:6 P4:0 really “P3:6” should be all you need (UART3 port) but for some reason mine would not work without P2 also placed at “6” (6= 115200 baudrate)
    5. save the changed config.ini file to the SD card along with the step 6.2 file above in this list.
    6. Power cycle the TFT35 and SKR while connected together.

Any help? I guess this is what you have already done…

4

Thanks for your reply. I wasn’t aware that it may be possible to just change the entries in config.ini. I’ll circle back to see if that’s all that was really needed.

I had re-built the .27.x.bin firmware file from the V1 source tree in PlatformIO, changing the definitions for which UART is used for P1/P2/P3/P4. That seemed to work.

I can make my own cable assemblies, so the connector remapping isn’t too big a deal for me. I’m debating doing some white wire surgery if it’s truly a blown UART to be able to use the original connector and cable. That’s a slight benefit as not every case has the holes present for UART3.

Yeah, essentially that. I have a USB FTDI and also some bluetooth ESP8266 serial bridges that I often use for embedded work- especially when I don’t want to risk blowing up anything more expensive than a $4 ESP.

I see it outside of V1 and not on the forums here.
That said, note these suspect TFT35s came from a very… V1 source. I wonder who that might be :thinking: …

1 Like