LCD screen stops functioning when also hooking up SCLK to Teensy SD adapter

Status
Not open for further replies.

Mike Chambers

Well-known member
Getting the final feature of my project working on my new T4.0 involves hooking up the Teensy SD adapter to the breadboard. The LCD screen works fine until I connect the SCLK of the SD board. These are the only two SPI peripherals on the board. I don't even have to connect MOSI/MISO/CS. I'm not really a hardware guy, I'm a software guy, but this points to the clock signal somehow getting screwed up by this connection.

At first, I thought it may have been introducing too much capacitance from the extra breadboard rail and it was causing the clock signal to not be clean enough. So I took the SD adapter off the BB and hooked it up directly to the pins with jumper wires. The LCD still doesn't work when it's connected.

The LCD I'm using is the ILI9341 that's available on this site.

Unfortunately, I don't own a scope to help me diagnose this. Any pointers for a hardware newbie?
 
Paul wrote this article some time ago, about better SPI design:

The simplest step is to try and use pull-up resistors on each of the chip select pins. I had a SSD1306 display that was somewhat flakey when I ran it with a SPI clock speed over 11Mhz on a Teensy 3.5, but when I added the pull-up resistors, it could go up to 19 Mhz without corruption.

You might try to check whether both the display and SD card use a proper tri-state buffer (see the article).

If you use ILI9341_t3, I believe it does have the proper SPI begin/end transaction.

One other thing that you would need one of the SPI experts to weigh in on, is you may need to switch the display from the DMA optimization mode for the display to normal SPI mode (if SPI.beginTransaction doesn't do that).

The only other thought might be to use separate SPI buses (you would need to solder two wires to the pads 26/27 underneath the Teensy towards the back, or solder the 1mm pads near the USB pad).
 
Thanks for the link. I will incorporate these tips, however it causes the LCD to stop working even without connecting MOSI/MISO/CS to the SD board. All I have to do is connect SCLK alone, leave the rest unconnected and the LCD functionality breaks.
 
I believe ILI9341_t3 is now using a very fast clock setting. Kurt has done pretty much all the recent work on that library, so I'm not as familiar with these details as I probably should be. But I recall seeing 30 MHz in the code recently...

It's possible the Teensy 4.0 pin isn't able to drive 2 boards at that speed. But also possible, it could be high speed signal quality issues like overshoot, ringing, reflections, etc. Can you show us photos of how the wires (including GND) are physically connected?

Teensy 4.0 is still very new. While so many of the libraries have been tested, we're still very early in the process of building practical experience with how various combinations work together. Teensy 4.0 is also able to drive its pins with far more bandwidth than prior boards. How this plays out in practice for various hobbyist & rapid prototyping construction techniques is still a mostly unexplored area. The pins in Teensy 4.0 have several ways to configure their drive strength & bandwidth. It's possible we're currently using a setting that is optimum for short directly connected wires, but not so good for 2 lengthy wires.

So please don't be shy to show us a photo of messy-looking wiring. ;)
 
As mentioned, I have done a lot of the work lately on this, but the actual change to run up to 30mhz was done quite a long time ago, I believe that the last change was simply to move it from the .cpp file to the .h file. To hopefully make it easier to find them and change if needed.

As for how best to configure the SPI pins on the T4? That is a question I am pretty sure I asked during the beta thread...

Currently they are all set for "fastIO" which may or may not be the best thing. Currently they are defined like:
Code:
	uint32_t fastio = IOMUXC_PAD_SRE | IOMUXC_PAD_DSE(3) | IOMUXC_PAD_SPEED(3);
	*(portControlRegister(hardware().miso_pin[miso_pin_index])) = fastio;
	*(portControlRegister(hardware().mosi_pin[mosi_pin_index])) = fastio;
	*(portControlRegister(hardware().sck_pin[sck_pin_index])) = fastio;

Suggestions and changes would be great.
@Paul (and Others) - this is also true for everywhere else we define IO pins for different things, like Uarts, Wire, ...
 
I believe ILI9341_t3 is now using a very fast clock setting. Kurt has done pretty much all the recent work on that library, so I'm not as familiar with these details as I probably should be. But I recall seeing 30 MHz in the code recently...

It's possible the Teensy 4.0 pin isn't able to drive 2 boards at that speed. But also possible, it could be high speed signal quality issues like overshoot, ringing, reflections, etc. Can you show us photos of how the wires (including GND) are physically connected?

Teensy 4.0 is still very new. While so many of the libraries have been tested, we're still very early in the process of building practical experience with how various combinations work together. Teensy 4.0 is also able to drive its pins with far more bandwidth than prior boards. How this plays out in practice for various hobbyist & rapid prototyping construction techniques is still a mostly unexplored area. The pins in Teensy 4.0 have several ways to configure their drive strength & bandwidth. It's possible we're currently using a setting that is optimum for short directly connected wires, but not so good for 2 lengthy wires.

So please don't be shy to show us a photo of messy-looking wiring. ;)

Sorry for the delay! I was at work all day.

Messy-looking wiring, you say? Now that I can do! Here it is. :eek:

https://i.imgur.com/szBhTg9.jpg

Ground is taking a bit of a long path to the SD adapter, but I've tried directly connecting it with a single wire as well, did not make a difference. The perspective of the photo makes it look like the wires are connected to the wrong pins on the SD adapter. They're not. I also left MOSI/MISO/CS to the SD disconnected for simplicity here because the issue can be reproduced without them anyway.

For good measure, I also tried to wire in the SD portion of a (3.3v compatible) Arduino shield. It caused the exact same issue with breaking the LCD display.

EDIT: Here's another angle: https://i.imgur.com/eXlpWlJ.jpg

Let me know if you can't make something out.
 
Last edited:
I'm just going to hook this up to some regular GPIO pins and do some bit-banging, I don't need huge amounts of bandwidth and I'm just trying to access the blocks raw. No file system needed.

If anybody has any ideas regarding the issue with sharing the bus with the LCD, let me know though! That would be a cleaner way to implement SD access.
 
Status
Not open for further replies.
Back
Top