This behaviour certainly caught me out for some time and had me scouring the miserable instruction set and guide for a while.
This is really a documentation bug. Sending anything other than a valid instruction causes the "00 FF FF FF" code to be sent - but here's the catch - only after the normal instruction terminator (FF FF FF) which tells the device to process the instruction. Therefore, sharing the serial Rx pin with other devices (e.g. a monitor) can result in something like "READY" (for the monitor) and "get n0.val"FF FF FF (for the Nextion) being incorrectly interpreted. The solution is to send FF FF FF before Nextion specific instructions.
This code is sent independently of the state of the bkcmd. The documentation needs to be corrected to the following:
Table 1: Execution Status Codes
1. Other than the Invalid Instruction, these codes are returned if bkcmd is set to 1.
2. Invalid instruction code is always returned after the first occurrence of the three termination bytes
3. Note that all messages are terminated with 0xFF 0xFF 0xFF
Hope this helps.
I have had a 0x02 0xFF 0xFF 0xFF error code
and it WAS reported in the Nextion v38 Debug screen as
PARSE: Invalid Component ID
This should be added to the Nextion Instruction Set Device Return Data.
I had this problem when error reply was in response to variable update of the inactive page and reply was not a '0' command but another NOT DOCUMENTED reply code '2' . As per your report, that one also was returned regardless of bkcmd being 0...
I knew I cannot expect fast fix from itead, so I made my code intercept all the junk coming from Nextion, before I search for a meaningful reply.
I don;t know if this particular reply (command '2') is still there or not, but apparently, similarly to my old post, reply is still coming when bkcmd=0... I can only guess how many developers get "surprises" in Nextion unexpected replies trying to figure out what is wrong...
Introducing an injected "NULL command" by sending just "0xFF 0xFF 0xFF" by itself may possibly lead to future problems if testing for the occurrence of an empty command string is not being checked for especially in user modified and enhanced libraries. There is no guarantee what new behaviour could be introduced by forcing a "process now" by sending just the terminator.
Um yeah, the instruction page is one fun document to refer to.
At the top of the page (Just under the Contents) is a NOTES section
1. The instruction is end with three bytes "0xff 0xff 0xff"
2. All the instrucitons and parametners are in ASCII
3. All the instrucitons are in lowercase letters
So the proper method is not to send a data terminating 0xFF 0xFF 0xFF before (as if to clear before use),
but rather terminate all instructions with the terminating 0xFF 0xFF 0xFF.
The confusion comes when we miss the notes section diving into the instruction we are looking for.
But the document has it stated - albeit maybe in a spot not being viewed.