Start a new topic
Solved

Invalid Instruction return data may catch you out

  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.


AHHHAAH!!



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.

Vlad,


I agree - if it occurs or can occur: it should be documented - even if the TJC developers thought they have programmed it from being a probability.  An else clause in our programming becomes necessary to catch these undocumented scenarios.

As users, without the code that causes the exception and ability for others to recreate the scenario, we don't really get to discover what the codes are relating to.  When TJC doesn't document, Itead can not translate - users are left scratching their heads. 

But if what caused it was disclosed to the user group - perhaps peers can replicate, discover and document to the group.  Too often I see "I was doing ___ what just occurred" with little or no clues, no source to explore, zero details of what led up to it.  (Violating everything necessary to troubleshoot).
If Itead programmers don't want/plan to stop error replies when bkcmd=0, then they have to put in documentation in writing this "feature" and suggest users to run code which intercepts everything from Nextion not matching their expected replies. This is THE ONLY solution.

 

@Leo   I reported this bug 5 months ago with ver0.34  in this post
Undocumented error '2' always returned regardless of bkcmd=0

 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.