No announcement yet.

uLCD-43DCT becomes semi-unresponsive after transmitting a large number of packets

  • Filter
  • Time
  • Show
Clear All
new posts

  • uLCD-43DCT becomes semi-unresponsive after transmitting a large number of packets


    I've been running into an issue for a number of months now, and it's both hard to diagnose and describe, but I've been unable to solve it and would appreciate help.

    My ViSi project started life as a Genie project which I converted. Since I have a large number of objects in this touchscreen app (165 buttons, 120 strings, 70 "videos" made up of just a few frames which I use as indicators), the Genie auto-generated code is a huge time-saver. Additionally, I have a rotary encoder attached to the screen's pins, and I've added code to generate Genie-like packets to indicate what the rotary encoder is doing as if it were a touchscreen virtual object.

    This project has slowly crept up in scale over the past 2 years, and after the most recent changes I started encountering the issue I'm posting about.

    Basically, I can throw as many packets at the screen as fast as I want. Today I tried redrawing an 8-character string roughly 100 times per second for 10 seconds, and everything continued to operate perfectly afterward. The issue seems to be when I either touch the screen very rapidly (i.e. drag my finger around across a number of buttons to do virtual button releases) or when I spin the rotary encoder very quickly (again, it's coded to be handled as if it were a screen object). Queuing up too many outbound packets often puts the screen into a semi-frozen mode where it will no longer output any packets in response to touches.

    The frustrating bit is that it still responds to the heartbeat poke code coming from the board it is connected to (it requests the current Form number every 15 seconds), and it will still update all strings on the screen. Additionally, if I send a large number of packets to the screen when it's in this semi-frozen state, it reliably recovers back to normal operation.

    I run the serial comms at 256000 baud, with the hope being that the serial buffers would not fill up. I have tried increasing the size of the Tx buffer, and inserted a few error printouts, but so far nothing seems to help with this issue. I believe there is just some weird memory situation with the Tx ring buffer, but so far I have not come up with a fix. I would be happy to share any of my code if that would help solve the issue.

    Here is a video which shows the problem I'm encountering:

    In the video, everything is operating normally at the start. I then "button mash," which is the same to the software as spinning the rotary encoder very quickly. After a few seconds of that, the screen no longer sends packets out, as indicated by the buttons no longer switching. I then send the screen a large number of packets very quickly, which update one string. After a few seconds of that, the screen resumes completely normal functionality.

    Any thoughts are appreciated. Thank you.

  • #2
    Hello Spencer,

    Based on the video, it appears that the display is still responding to touch even when it's supposedly lagging (the borders of the other buttons still seem to change color).

    You might want to checkout this sticky post for additional tips.

    If none of those work for you, kindly post a copy of your project.

    Best regards,


    • #3
      Hello Michael,

      Thanks for the reply. I looked over the stickied post, and I am safe on all of those bullet points. The display is definitely responding to touch while lagging, but the freeze issue I'm describing is different. What I believe is happening is that the main touch processing loop of the 4dg code is still operational, but the TX buffer is overflowing and corrupting some other portion of memory (even though it's allegedly a ring buffer). This means that the screen is no longer outputting packets, but will still receive both packets and touches.

      From what I can determine, the TX (out from the screen) comms cease to work once com_Full() becomes true. I have tried increasing the size of the buffer and speed of comms with no luck. What is really puzzling to me is that the TX buffer becomes functional again after the screen receives a large number of packets, which I showed at the end of the video. To me, that seems like some kind of internal memory management issue, but I am struggling to find a way to debug it.


      • #4
        Hello Spencer,

        I believe this might be more of an issue with data transmission management rather than internal memory.

        For example, if you're sending the same data over and over again, it might be helpful to just send it when its value has changed.

        As you've mentioned, this bug occurs when you button mash the display, have you considered creating a function that would limit the frequency of pressing the screen?

        These tips are all very general, I might be more helpful if you could provide a copy of your project, if you're uncomfortable on posting it here, you could send it to me via private message.

        Best regards,