Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 16 of 16

Thread: ILI9341 Touchscreen X and Y touch values swapping places Intermittently

  1. #1
    Member
    Join Date
    May 2015
    Location
    UK
    Posts
    25

    ILI9341 Touchscreen X and Y touch values swapping places Intermittently

    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).

    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

  2. #2
    Senior Member
    Join Date
    Nov 2015
    Location
    Wales
    Posts
    579
    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?

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    24,005
    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.

  4. #4
    Member
    Join Date
    May 2015
    Location
    UK
    Posts
    25
    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

  5. #5
    Senior Member
    Join Date
    Nov 2015
    Location
    Wales
    Posts
    579
    Quote Originally Posted by Twinscroll View Post
    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

  6. #6
    Member
    Join Date
    May 2015
    Location
    UK
    Posts
    25
    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.

  7. #7
    Senior Member
    Join Date
    Nov 2015
    Location
    Wales
    Posts
    579
    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

  8. #8
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,762
    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.

  9. #9
    Member
    Join Date
    May 2015
    Location
    UK
    Posts
    25
    Thanks for the advice guys.
    @defragster, I was hoping you'd see this thread and it catch your interest ;-)

  10. #10
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,762
    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 by defragster; 02-05-2016 at 07:12 PM.

  11. #11
    Member
    Join Date
    May 2015
    Location
    UK
    Posts
    25
    Thanks defragster, I'll give it a try.

  12. #12
    Member
    Join Date
    May 2015
    Location
    UK
    Posts
    25
    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 !
    Attached Files Attached Files

  13. #13
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,762
    @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.

  14. #14
    Member
    Join Date
    May 2015
    Location
    UK
    Posts
    25
    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 !
    Attached Files Attached Files
    Last edited by Twinscroll; 02-08-2016 at 11:05 PM.

  15. #15
    Senior Member
    Join Date
    Nov 2015
    Location
    Wales
    Posts
    579
    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 by Xenoamor; 02-09-2016 at 09:00 AM.

  16. #16
    Member
    Join Date
    May 2015
    Location
    UK
    Posts
    25
    Hi Xenoamor,

    Thanks for the suggestions, I will give these a try and feedback.

    Best regards

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •