cancel
Showing results for 
Search instead for 
Did you mean: 

xpt2046 touch controller

kob77
Associate III

Hi, I'm having trouble with the resistive touch screen on my display. Here's some info about my project - I'm using an stm32f401cdu6 microcontroller, a 7" display with an SSD1963 controller, and a touch controller XPT2046. I based my project on the offpic user libraries on GitHub. You can find my microcontroller configuration and source files at https://github.com/koob7/stm32-f401-display. The display works fine, but the touch only works in power mode (XPT PD1=0, PD0=1). The first issue is the synhronic generation of interrupts on the irq pin even when the screen isn't touched. This happens even when interrupts are disabled (XPT PD0=1). In the future, I'd like to only read touch input when it's actually pressed. The second problem occurs in power-down mode (XPT PD0=0): when I change the X position on the touch, both X and Y values change. A similar issue happens when changing Y.

29 REPLIES 29

Yes, that's correct, I'm using the same SPI for the XPT and the reader with separate CS lines. Unfortunately, I haven't gotten around to getting an oscilloscope yet, but I plan to buy one in the future. I've written a simple program to handle the reader, and everything works fine (whether with or without the display connected). I assume that in this situation, the XPT isn't causing any issues. My reader is https://botland.store/memory-cards-accessories/8230-micro-sd-card-reader-module-5904422311278.html It has a built-in linear regulator and a 74HC125.

OK, the person designing the card reader was thinking (I hope). The 74HC125 isolates the card and provides more drive than the card itself will. So the problem is very likely not the card reader.  (Until we make sure)

I assume you have a voltmeter?  (and good idea on the scope, if you start dealing with hardware, you'll likely need one). 

With the processor paused, and not in the routine to read the chip, check that the CS on the XPT is high.  With that high, the MISO line will likely be low (not floating).  The MOSI line should be floating or high.  The CLK line should be floating or high.

With the MISO line low, the HC125 should not be active.  Make sure that the CS line on the card reader is high.  A good test would be to disconnect the MISO, MOSI, and CLK lines from the card reader, then with the CS line high, check that the lines are floating.  They should be. 

Without an oscilloscope, you have some difficulty in determining what is going on with the circuit. 

The problem with the XPT is that, in an SPI chip, the outputs are supposed to be floating when the chip is not selected.  This allows paralleling two SPI chips and controlling each with the separate CS line.  The XPT hogs the data out line (MISO) and prevents data from getting through from other chips. 

Now if the card reader is properly designed, the HC125 isolates the card, and therefore does not drive the MISO line when the card reader CS is high.

IF.......

That's what the check on the card reader by itself will do, see if the card reader is well designed. 

On the boards that I use, I designed in the HC125 chips for each line paralleled from the card and display that is an output, the MISO line from each. I don't have the problem.  The reason that I don't have the problem is that I DID have the problem.

A logic probe might work well if it handles 3.3 volt levels properly.  It can show levels and activity. 

 

 

 

I took measurements and the results are as follows: MISO and MOSI are high, SCK is low (SD card reading program), MISO is high, MOSI is low, SCK is low (display handling program). In both cases, both CS pins were high. What you're saying seems to make sense. I think I can confidently consider the problem solved by adding the HC125.

Now, I would like to design a board with my supervisor using a Cortex-M7. On the board, most of the pins will be GPIO + SPI pins + programmer pins. Do you think this is feasible with relatively little effort based on existing schematics? Or do I need to have a full understanding of the processor documentation? Or perhaps you'd like to help me with this for some fee?

I thank you for the vote of confidence. 

I do have pointers for processor designs, but I will warn you that it may be more useful to start off with a smaller and potentially cheaper processor for learning purposes. 

While you can do a 2 layer board for microprocessors, once you get into the high clock speed  (say over 50 Mhz), I'd recommend a 4 layer board:  top layer, ground plane (no traces), possible signal plane or power plane, and then bottom layer.  Someone needs to know how to use a PCB design program and have some experience.  It made a difference in the design to go to 4 layers.

You also need to play a few games when dealing with high speed clocks (SPI signals) and perhaps programming signals.

You'll also need an oscilloscope, preferably a 4 channel, 100 Mhz plus model, or access to one.

The existing schematics are good starters, but you need to understand why they did what they did, and at times, why they shouldn't have done that.

This can be more complicated than you think, so I'd start out really simple.  I'm not sure how happy you are with some of the design processes, nor how much experience you (or your supervisor) happen to have.  Is this in an academic or a work situation?

There will be a fair amount of learning involved, so you may be moving a bit fast.  You might want to check out projects with the Nucleo board series. 

So what are your goals?  What do you want to learn?

 

So, starting from the beginning. Yes, I'm a student of Computer Science at POLS. In my second year, I decided that for my engineering project, I'll create a 6DOF robot (I have support from the project supervisor). The project involves:

-creating my own design (done - maybe not perfect, but sufficient for me)

-formulating inverse kinematics equations for robot control (also done)

-creating a controller responsible for:
*controlling the robot's movement (done on a Nucleo board)
*creating a GUI for robot control (I connected a 7" SSD1963 screen and touch panel to a Blackpill, but it requires GUI programming, which seems like the easiest part to me)
* controlling the robot using G-code read from an SD card.

All of this results in a mass of cables that are unsightly and create a huge mess. Not to mention that I have to transfer all of this to one microcontroller (a project requirement), which will introduce even more confusion.

To reduce noises my idea is to divide the board into two parts :
- a part for stepper motor drivers (requiring a lot of current)
- a part for the microcontroller

Unfortunately, I don't have experience in PCB design :C. Fortunately, the board will be relatively simple (reset circuit, quartz oscillator, SDRAM memory (if I manage), programming interface, basic short circuit and overvoltage protection).

Of course, starting with simpler circuits is more sensible, but unfortunately, the time I can dedicate to the project is severely limited. That's why I decided on a project with a large microcontroller. I plan to solder the components gradually, measuring all voltages and potential soldering errors. In case of major problems, I'll resort to a ready-made Nucleo solution.

I'm attaching a short video showing what I've managed to do so far :D

I've tried and worked a bit with some things like what you're doing.

It's actually a bit easier to have multiple processors, but that's not the requirement.

Considering all that you have to do, I'd buy as much of the hardware (ex: CPU board) as reasonable.

I'd use a nucleo-144 board with a processor that has lots of memory. 

I'd design a PC board into which the N-144 board plugs, which takes connections and brings them out (through circuitry if needed) to plugs. This ought to considerably neaten up the wiring.  You might consider a small OLED display to do status, not the main display.  This PC board can be a 2 layer board, and should be reasonably inexpensive.  If you don't design a board, then perf board on a base board (standoffs!) and make it modular. IDC connectors between boards. 

The two sections are good, with all the drivers on one board, and the sensors on the CPU backboard. 

There's a problem with the Nucleo boards, and that is "no idea how they routed the signals".   High speed FMC signals don't work well for dynamic memory, static memory, where you can control the timing a lot better.  You can do SPI interfaces reasonably because they can be slowed down.  There are some SPI memories that can function as RAM and might be easier to use.  For ROM, I'd suggest an SD card. I2C can also be used for ROM (24LCxxxx memory). 

Check I2C specs and SPI specs to see how far they can be run. 

Look into power grounding techniques with high current vs low current.

What you might want to do for overall development, is get a board set up where you can plug in an N-144 board, then wire to the appropriate connectors.  Do you have wire-wrap available?

I really suggest not doing your own CPU board, using the N-144 board you will have something that works out of the box, you just have to be moderately careful with how you connect things.  Note that the evaluation boards, while more complete, have a limited amount of I/O, please check.

I will not design stuff for you, but I'll be able to help to a limited extent.

 

I'm well aware that using the Nucleo board significantly simplifies things. Actually, I've already designed such a "sandwich" for this project, but many things have changed and require redesigning. I'll reconsider the memory issue; it's possible that the 2MB on the Nucleo F144 will suffice. On one hand, I realize the immense challenge I'm facing, but on the other hand, I felt similarly when starting the entire project. I think I'll at least give it a try. If the expected results aren't achieved quickly, I'll stick with the Nucleo F144.

I'm not sure what you mean by "wire-wrap." I soldered my project on a prototyping board, replacing the traces with wires.

The redesigning is why you may want to consider modules (that you design and build).  Change a section, just change the module.  Not sure if the 2MB (FLASH) will be enough.  Always easier to plan for it and just leave the module out.

On projects, pick your battles wisely.  The less you have to build (the hard way) the more you can spend time on fixing the whole design.  It's a balance that evolves over time.  My first designs started with Nucleo boards, which was fine until I ran into the limitations of such projects.

wire wrap is a very reconfigurable method of construction.  Ask your supervisor, but it's not likely you will use it because I rather doubt that the technology is available. 

 

 

Okay, I'll think over the whole issue and make a decision. Thanks again for your time and the knowledge you've shared. It's really important to me.

Glad to be of help.