Nextion recvRetNumber err help?



I am using @ScruffR ported Nextion library to communicate the P1 module with Nextion display.

The problem I am facing is recvRetNumber err with the below code:

//blacklight button released
void bLightSavePopCallback(void *ptr)

  uint32_t dimVal = 0;
  uint32_t dimTim = 0;
  uint32_t slpDim = 0;

  int bDimValue;
  int bDimTime;
  int bslpDim;

  bslpDim =(int)slpDim;
  bDimTime =(int)dimTim;

  //blacklight store in Eprom
  char bLightArray[11];
  bLightArray[11] ='\0';
//  EEPROM.put(510, bLightArray);

  Serial.printlnf("(bLightSavePopCallback) bDimValue: %d bDimTime: %d bslpDim %d", bDimValue,bDimTime,bslpDim);
  Serial.printlnf("(bLightSavePopCallback) backlight bslpDim,bDimTime,bDimValuearray: %s", bLightArray);


Output log:

recvRetNumber err
recvRetNumber :1
recvRetNumber :2
(bLightSavePopCallback) bDimValue: 2 bDimTime: 1 bslpDim 0
(bLightSavePopCallback) backlight bslpDim,bDimTime,bDimValuearray: 1,0,1,2

As the output log show, this will mess up my values and array into the eeprom. But if I uncomment the //delay(30); and rerun the code the output seem to be good.

output log with no err:

[ 536872952:6,3,page3.bSave,(null)]
recvRetNumber :1
recvRetNumber :1
recvRetNumber :15
(bLightSavePopCallback) bDimValue: 15 bDimTime: 1 bslpDim 1
(bLightSavePopCallback) backlight bslpDim,bDimTime,bDimValuearray: 1,1,1,15

I am using:


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

The max index for an [11] is 10 - 11 is out of bound.


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

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.

For the below example, 1(status)+1(bslpDim)+1(bDimTime)+3(bDimValue)+3(,)+1(’\0’)= 10 . Correct?


Just read up on snprintf(), snprintf() does look better and it add terminating null. @ScruffR, thanks for the suggestion.


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.


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 :sunglasses:


@ScruffR, Thanks for pointing it out, I need to be more careful next time around. I have change my code to use snprintf() and shrink my array accordingly. :slight_smile: