I have other PopCallback calls in the code but only this one I need to add the delay. My guess was the Serial1 is busy in the same time the above code was executing which cause the recvRetNumber err. I am not 100% sure by adding a delay will fix the err. Could any one help out with this? Are there other way to see if serial1 is free before I do a getvalue or adding a delay will solve this issue? Thanks.

It’s hard to say what exactly causes the problem, but a common issue with this library is that display and host controller are running asynchronous but share one resource.
So your touch events may come at any arbitrary time and cause immediate transfer which might collide with transfer initiated by the host controller. A delay can help stretching things apart enough to reduce collisions.

I once started to add some queueing mechanism into the library but that initiative has stalled due to more important needs on other frontiers.

The best option with the current implementation might be to check return values and retry the read on failure.

BTW, your numbers will never be longer than two digits with only ever being two out of three being two digits at the same time?
If all three figures are two digits (or more) at the same time your bLightArray[11] will be too short. Using snprintf()might be better.
And this is not allowed with a bLightArray[11] either

@ScruffR, if I remember correctly, the getValue does provide a return value of true or false? I will need to add some checks, what worries me is the collisions as you mention above at any arbitrary time. I notice other parts of my code having some err for command fail since its in a loop it can correct itself so I didn’t add any checks.

ScruffR:

BTW, your numbers will never be longer than two digits with only ever being two out of three being two digits at the same time?
If all three figures are two digits (or more) at the same time your bLightArray[11] will be too short. Using snprintf()might be better.

A little explanation how I figure the size of array, I am using 1 digit for status (0 or 1), 1 digit for bslpDim (0 or 1), 1 digit for bDimTime (0 or 1 or 2 or 3), 3 digit for bDimValue max (0-100) and plus the , .

Please let me know if I am calculating the size of the array correctly, I did ran into EEprom corruption before. Not a fun thing. lol.

With that info that only one of the three variables can have more than 1 digit (max. 3) it’s safe to us a char[11] but adding the zero-terminator at the 12th position bLightArray[11] is still “dangerous”.

@ScruffR, why would it be dangerous to put a zero-terminator at the 12th position? What would you suggest I do differently?

What I want to do is to combine the three variable and a status variable into a char array and put it into EEprom. I believe I need to zero terminator the char array before putting into EEprom so I can get the value when I need it later on from the EEprom.

why would it be dangerous to put a zero-terminator at the 12th position?

You are declaring an array with 11 elements, indexed 0…10 and then writing to the element with the number 11 (so actually the 12th element) you will be corrupting data immediately following your reserved space.
Depending on what exactly that following byte you just overwrote contained you may cause unexpected behaviour, depending on what your program would do with that now corrupted variable (which might even be a callback address your code might be jumping to next).
For more exposed systems this would be the spot where hackers would cry out with joy since you just opened a door for them to inject malicious code.

Lucky for you this is a 32bit µC which padds variables to always start at a 4byte boundary, so your 12th (not reserved) element will not overlap into an actual variable - but that was mere coincidence I guess