ILI9341 Touchscreen X and Y touch values swapping places Intermittently

Status
Not open for further replies.

Twinscroll

Active member
Hi.

I have a strange issue with my 320 x 240 - 2.8" ILI9341 Touchscreen display and was wondering if anyone may have any ideas as to what may be at the route of the issue!

In summary as per the title of this thread, The values being reported for the touch location of "X" and "Y" - are intermittently swapping places.

Below is a small extract from a serial dump of the X and Y positions.
I am keeping my finger in the same place on the screen, but notice the middle line where X and Y have flipped.

X = 855 Y = 2863
X = 860 Y = 2876

X = 2853 Y = 864
X = 855 Y = 2881
X = 857 Y = 2863


This Swap of position is only brief, but it is causing me a headache on my project, as on my final code I am drawing a 'virtual' line down the middle of the screen and use the value of X to either show the "next" screen, or to show the "previous" screen data. i,e as a menu / screen select control.

My hardware setup is a Teensy 3.1 and I am using the Micro SD card on Pawelsky's CAN bus board - https://goo.gl/byHlgs
The SD card initialises every time and the SD card logs fine, so I dont think this is directly hardware related.
I am not sure but there appears to be something undesirable happening between the SD and Touch when using the SPI bus?

My final project code is quite large & still in progress but in order to show this issue (or at least it looks to be the same) - I have updated the Touchtest.ino example code to include the SD card and show the same Intermittent issue (this is what I used to gather the example data above).

View attachment Touch_and_SD_Card_Cutdown_Code.ino

Note in the main loop of the attached Touch_and_SD_Card_Cutdown_Code.ino code example -

// Once this Section of Code is introduced the Intermittent X and Y flipped begins.
/*
myFile.print(p.x); // Write To SD Card
myFile.print(","); // Write to SD Card
myFile.println(p.y); // Write to SD Card
*/
// Note currently for the purpose of simplifcaiton on this cut down code the SD card is not Closed or Sync'd / Saved.


On my end application the user is not holding their finger on the screen constantly, but I do make regular writes to the SD card (Including a Sync ~ every 1 second).
I was finding some very odd behaviour and found the X & Y swapping to be at the route of the issue.

Does anyone have any thoughts or suggestions what I might be able to try?
Currently on my final code, I am reading the position of X multiple times and taking an average of the readings, but this is not 100% reliable, and is only a workaround.
Can anyone else try and recreate this issue?

Best Regards
TS
 
Weirddddddd

Maybe try:
Code:
myFile.print(String(p.x));              // Write To SD Card
  myFile.print(",");              // Write to SD Card
  myFile.println(String(p.y));            // Write to SD Card
Just to ensure print() is correctly casting it?
 
Does the problem continue if you remove all the SD card stuff? Is see you're opening the file, but code to actually use it is commented out.

It'd be nice to know it's related to SD usage, and if not... a simpler test program to reproduce the problem would be really nice.
 
Hi Paul.

If I remove the SD card code completely (from the attached example code) it is functioning 100% as expected.... i.e the X and Y never swap.
I have been battling along with this for a little while now, trying various things but maybe I need a deeper level of understanding on the SPI side of things.
Something that has just come to me, do you think it would be worthwhile trying the standard SD.h library rather than the SDfat?


Hi Xenoamor,
I will give your comment a try and feedback once tested.


Thanks Guys
TS
 
Hi Xenoamor,
I will give your comment a try and feedback once tested.
I don't think this is causing the issue now, sorry! But you are welcome to try it

It seems quite quirky to have a while(1) loop in your main. I think the Teensy needs to be able to exit the loop() function to service serial communication
 
I take your point about the while 1.
I pulled this together really quickly and wanted to keep it slim.
My main program does not contain that while 1 code - and still shows this issue.
I will rewrite this simplified code, without the while 1 and feedback if any different.
 
It maybe worth slowly pulling out bits of the SD card code until it starts working again.
Just to narrow it down a bit. It's almost certainly a low level issue and it would be handy to know which function is causing it
 
When I get back to my touch code for buttons I'll watch for this. I have noticed a spasm at some points but not been looking at the values. I had two active display units - one was using the SD interface.

What would show was hits in a button under my finger - then suddenly a neighboring button would fire. Odd to have it be this though since it takes two hits on a point (+-3) to call a hit.

Also saw jumps on Paint Sample - touch drawn would jump - but not across an X,Y diagonal as if swapped.
 
I have a sketch I had posted before I completed the move of the INT code to the core library. :: IntTouchPaintDeb_SD
Not sure if that ino was dropped on the forum or only GitHub, where I pulled it.

Perhaps I'll update that ugly thing to use the released 1.27 int code as it did some use of the SD card and repost it - printing a dir - to see if it shows anything in the drawing a pixel for each touch point.

@twinscroll - that was in Nov posted to you then - maybe you have a copy, but it wasn't dropped on the forum: ILI9341-restive-touch-miso-not-connected
 
Last edited:
I managed to get a small amount of time on this again today - I updated my simple test code to use the standard SD library (removing all references / use of the SDFat library).
The updated code is attached below.

Result of test = The intermittent X / Y swap issue is not present if I use the standard SD library....

I was really hoping that the fault remained present, as I very much like lots of the features that the SDfat provides above the standard SD library.

- I will need to test on my full code, with the standard SD library now.

Being honest with myself, I feel that I am out of my depth on looking into / debugging why this difference between the 2 libraries occurs.
Is there a bug list somewhere that I can register this against? In case someone with a better understanding gets chance to look one day !
 

Attachments

  • Touch_and_SD_Card_Cutdown_Code_NOT_SDFat.ino
    3.4 KB · Views: 102
@Twinscroll - sounds like you did good to isolate part of the problem! I didn't look that closely to see that different libraries involved.

I'm looking at ESP8266 w/Teensy right now and don't have an active SD card.

The good news is the Touch driver can and does work - there must be some bad effect of the SDFat on the SPI would be a first guess. But, the driver asks for the X locations then the Y locations - but I don't see how random interference would perfectly exchange those two values as there are three reads of each in succession - at most it would corrupt one that would be discarded or averaged - not get them swapped. and more likely it would corrupt the whole read process. Does the SDFat use interrupts? I did the interrupt touch response - but in a way that it only sets a Touch driver state variable allowing polling to proceed - not actually processing a read as that would either block or interrupt on other SPI in progress. It is more likely local data corruption - but how it would be so precise as to swap X,Y is a mystery that goes away with the other driver?

Perhaps if @Paul reads this it will ring a bell as to how or where it could be traced. If you could do the simplest example maybe for touch that plotted the x,y on the screen as well as out the debug. My one sample would clear the screen after a few seconds of no touch to start on a clean screen then map and plot each x,y a steady finger should never plot anywhere across the screen. Then find a way to call SD .vs. SDFat to do something simple between touch reads and provide a way to reproduce it.
 
Hi,

I have been making a few more tests on this code again tonight - and I have managed to narrow things down quite a bit.
Either that, or I have written an impressive bug.

I have kept SDFat in the code and I have introduced a small loop into the code to write a selectable amount of data Bytes to the SD card.
I have found that the swap of X and Y occurs after 512 Bytes has been written to the SD card.
512 Bytes is the size of an SD card "sector" size, or maybe 1024MB (Card type dependant) - so maybe something related to this is/must be occurring .......... does anyone have any ideas or suggestions?

The following extract of code is from my updated simplified file as attached.
Update the "number_of_bytes_to_write" value as required for the test.

///////////////////////////// Select Data size to write to the SD card ///////////////////////////////

int number_of_bytes_to_write = 128; // Update this number to select the data size to be written to the SD card..

for (int byteswritten = 0; byteswritten < number_of_bytes_to_write; byteswritten ++)
{
myFile.print("X"); // Write one BYTE to the SD card.
}

// Write "1"byte - Touchscreen X and Y swap occurs after 512 cycles of 1 BYTE
// Write "2" bytes - issue occurs after 256 cycles
// Write "4" bytes - issue occurs after 128 cycles
// Write "8" bytes - issue occurs after 64 cycles
// Write "16" bytes - issue occurs after 32 cycles
// Write "32" bytes - issue occurs after 16 cycles
// Write "64" bytes - issue occurs after 8 cycles
// Write "128" bytes - issue occurs after 4 cycles
// Write "256" bytes - issue occurs after 2 cycles
// Write "512" bytes - Things go a bit crazy!

///////////////////////////// End of data size to write to the SD card ///////////////////////////////


This is from the serial output stream when writing 4 blocks of 128 BYTES.

LOOP COUNT DELTA = 4
LOOP : 281 : X = 809 Y = 2033
LOOP : 282 : X = 811 Y = 2029
LOOP : 283 : X = 808 Y = 2036
LOOP : 284 : X = 2025 Y = 792
LOOP COUNT DELTA = 4
LOOP : 285 : X = 786 Y = 2010
LOOP : 286 : X = 780 Y = 2018
LOOP : 287 : X = 783 Y = 2000
LOOP : 288 : X = 1982 Y = 779
LOOP COUNT DELTA = 4
LOOP : 289 : X = 783 Y = 1973
LOOP : 290 : X = 787 Y = 1966
LOOP : 291 : X = 775 Y = 1956
LOOP : 292 : X = 1964 Y = 776
LOOP COUNT DELTA = 4


This is from the serial output stream when writing 8 blocks of 64 BYTES.

LOOP COUNT DELTA = 8
LOOP : 73 : X = 1069 Y = 1929
LOOP : 74 : X = 1063 Y = 1925
LOOP : 75 : X = 1076 Y = 1923
LOOP : 76 : X = 1073 Y = 1936
LOOP : 77 : X = 1072 Y = 1920
LOOP : 78 : X = 1046 Y = 1930
LOOP : 79 : X = 1067 Y = 1914
LOOP : 80 : X = 1932 Y = 1067
LOOP COUNT DELTA = 8
LOOP : 81 : X = 1069 Y = 1927
LOOP : 82 : X = 1066 Y = 1936
LOOP : 83 : X = 1064 Y = 1930
LOOP : 84 : X = 1065 Y = 1914
LOOP : 85 : X = 1066 Y = 1922
LOOP : 86 : X = 1075 Y = 1848
LOOP : 87 : X = 1065 Y = 1925
LOOP : 88 : X = 1928 Y = 1064
LOOP COUNT DELTA = 8


Note I am holding my finger in the same place on the screen during this test.
As this code is currently looking for a change of >500 on the value of "x" compared with the previous loop, code works best on either side of the screen where the value of X to Y is large.
Once the large change is found, It will print "LOOP COUNT DELTA".
The X and Y values do continue to flip regardless of where you place your finger, but just keep the above in mind.

Any ideas / suggestions or thoughts would be great !
 

Attachments

  • Touch_XY_Swap_Byte_Count_selectable.ino
    5.3 KB · Views: 99
Last edited:
I'm fairly unfamiliar with c++ but doesn't
Code:
myFile.print("X");
mean
Code:
myFile.print('X');
myFile.print('\0');

No idea. Either way this is more a curiosity then anything

Can you try calling file.sync() in the for loop after you write and see what happens?
My understanding is SDfatlib buffers every 512bytes before updating the SD card


EDIT - You should be using myFile.print('X') though which according to the header files will call sync() after every write where as myFile.print("X") will do it every 512

Just for my future reference file::write(.. exists on line 1350 of FatFile.cpp
 
Last edited:
Status
Not open for further replies.
Back
Top