Start a new topic

Multiple 0xFF returned after every transmission

Hi colleagues!


I’m using an Intel Edison kit and the code for it is written in C++ using the Intel System Studio IOT Edition. I use mraa library functions (libmraa) to transmit data through the UART.


Everything works as expected when I debug in the Nextion Editor environment.

However, while working with the Nextion Enhanced NX4827K043R, I noticed some unexpected events which I could not handle.


The problem is this:

After sending each command to the Nextion module, I encounter a large amount of 0xff bytes after reading the buffer contents.


I use the following parameters:




With these parameters, it would be natural to suppose that I can be sure that I will not receive any reply generated by the Nextion module after sending something to it. Nevertheless, a large amount of 0xff bytes are returned (although the amount differs for every command).


For example:

A 17 byte command (including 0xff,0xff,0xff) will return 16 0xff bytes.

A 47 byte command returns 42 0xff bytes.

A 35 byte command returns 31 0xff bytes.


How can I get rid of this redundant data which is sent back after every transmitted command?

Nextion Return Data is described in the Nextion Instruction Set.

Sending 0x31 0xFF 0xFF 0xFF is not a valid nextion command - ever. It equates to a command of 1 with Nextion Termination to begin processing.  So yes, it rightfully should send back an 0x1A 0xFF 0xFF 0xFF but only if conditions for sending Nextion Return Data have been met. (option exist where no Return Data would be sent, in which such would not be received).

There is no 0xFC purposefully delivered by Nextion.  For an 0xFC to occur, this would have to be part of some value being returned.  This is a misinterpretation of the 0xFC you are perceiving.

The connect command is documented and published by commercial request in the Upload procedures for advanced purposes of either preloading TFT files, or swapping TFT files out on the fly.  You can find this document in the Itead Blog, and linked in the Tools, Tips, Tricks and How-TOs in Nextion Gallery.  This is also implemented in the NexUpload.cpp that accompanies the Iteadlib Arduino Nextion Library.  The use of connect is just connect, without parameters or attributes.

Most users are actually not Arduino, this is a misconception, but the vocal ones asking the most questions are indeed Arduino users.  STM32 and PIC users far out way Arduino, and there are 1000s of MCUs used with Nextion.

Now, in all my experience, and now especially with an 0xFC byte

- I believe your issue is on your MCU side communications.

- there should be no need to send to Nextion a baud or a bauds command

  unless you are purposefully changing the baud rate to be used by Nextion

  - this can and most likely will result in unexpected behaviour

    (you are experiencing such),

    and I would recommend a reboot with rest command if a bauds command has been sent.

You could look at the Iteadlib Arduino Nextion Library as a guide.  It is good practice to send an empty command when starting connection.  This is close to what you were doing with your 0x31 0xFF 0xFF 0xFF but only 0xFF 0xFF 0xFF (which triggers processing of nothing, but ensures a clean position with Nextion side buffers).

But there is no commands where Nextion would send a stream of 0xFFs, unless user data contained such.  Nextion Return Data is terminated with only three 0xFFs.  Therefore, I would dig into your underlying communications on your MCU side.

I strongly suspect there is a misinterpretation being made to arrive at a conclusion of so many 0xFFs, furthered by the 0xFC.  This could be within the libmraa implementation as it drifts further away from its Edison base, or in Intel's software bit-banging implementation of a UART. The Edison does not have real UART or dedicated hardware supporting their implementation.

Now, I will add the Nextion firmware runs an interpreter to step through the users loaded HMI design on the Nextion device.  This is driven by a much much smaller single core, single threaded, limited interrupt, sequential processing STM32/GD32 MCU.  As such, Return Data is sent at the end of processing, this can be a few ms after the command is received.  (Even longer if the Nextion is being overloaded with command requests to fulfill).  I would be suspect that the ratio of misinterpreted 0xFFs is caused from a polling nature of bit-banging the serial and filling in "empty time" with 0xFF.  I might look for a non 0xFF byte matching the Nextion Return codes at the 3rd from last byte position and perhaps it is not an entire stream of impossible 0xFFs.

So, these are my thoughts, conclusions and suggestions on your issue with your Edison issue.  But Nextion is just a much more simple TTL text based device.  I am not sure if Intel supports (truly answers such detailed questions about) the libmraa, and suspect it would be much less so after libmraa expanded beyond its Edison roots.  Many things are going to play into even which version of libmraa you are using.

But as I know from Intel, they provided you a platform with many many many means to create your project.  This is your choice to pick Studio IOT and libmraa.  GCC and python are preloaded.  Heck even Arduino sketches are supported.  But mostly, it is a dual core Linux with the RTOS MCU - meaning you had just about any language you desired.  Truly a platform of open choices for the developer.  But libmraa is not the only means to establish communications.

So you now have the base of Nextion explained.  I would go back to the Intel Forums and query into libmraa 151.  If it is an issue, I know there is an older version on Alex's repo.  But this is all beyond scope of Nextion display support.

Just to add so the ending is not misinterpreted.  Free Chat is indeed available for Nextion discussions.

And welcomed even more so once you have stabilized your MCU side communications.

Thank you guys for such a detailed analysis!

I have already considered everything that you have mentioned in your reply as I was thinking along a similar path. In order to move forward I had to be sure that my trick to take care of the 0xFC bytes that Edison sends to the TX line by sending a 0x31 0xFF 0xFF 0xFF sequence does not switch Nextion into a different, unknown mode.

Now that you have confirmed that this has nothing to do with Nextion I can focus searching in a different direction.

I share the ideas you have put forth and it's quite possible that they are true.

As a simple, temporary solution, I can just flush the buffer from all the useless 0xFF bytes because there are no other issues I have encountered apart from these sequences of garbage.

Once again, a huge thank you for your timely replies!

One more bit of information that may finally help.

Nextion on clean powerup will send out what looks like

XXXX  0x00 0x00 0x00 0xFF 0xFF 0xFF 0x88 0xFF 0xFF 0xFF

Where XXXX are floating pins before initialization (no meaning derived from)

0x00 0x00 0x00 0xFF 0xFF 0xFF - Nextion has started restarted (a preamble)

0x88 0xFF 0xFF 0xFF - Nextion now ready.

on a rest command reset is common that just 0x88 0xFF 0xFF 0xFF is received

Also ensure a basic Nextion side baud rate confirmation.

(Necessary to rule out a baud rate of -1)

  - Create blank.hmi with n0 component

  - post initialize event code


  - build and install on Nextion device

  - run HMI

IF baud rate shows as -1 then

  - set postintialize event code to

    bauds=9600 // or desired 

  - rebuild, reinstall and run.

Baud/bauds should no longer need to be sent over serial.

  (unless setting default power on baud rate to other)

revisit the bkcmd setting (can also be issued via preinitialization in first page of HMI)

   bkcmd=0 will not respond with success/failure, bkcmd=3 is good for debugging.

  (Nextion default is bkcmd=2 on power up)

The concern is that phantom 0xFFs will not just effect Nextion Return Data

   for success or failure return codes, but also more legitimately the necessary

   0x65, 0x70 and 0x71 (and other) Returns needed for running HMI.

   (so cause of FF stream needs to be isolated so it doesn't interfere)

Other considerations require which hardware is being used for Edison

   Arduino, Mini Breakout, Sparkfun's Blocks (UART block is interesting), or custom.


Concerning hardware, mine consists of an Intel Edison Kit for Arduino paired with a shield from the Grove starter Kit for Arduino

Something that might be tested

  - perhaps try an Arduino sketch to see if Arduino produces the same results

  - I don't see an Arduino sketch as interfering in current Studio IoT project

    more of independent code for a side line test.

Also what was result of Nextion side baud rate confirmation ...

  (two Nextion devices presumed to have escaped with a -1 setting)

First off, concerning the parameters of my Nextion:

The initial 'bauds' parameter was -1. I found this out only after testing the display but it didn't affect the performance. Once I had noticed this, I figured out that I had to act as you have suggested and did so.

Currently, my baud=9600, bauds=9600 and I do not use any commands to change them.

Concerning trying out an Arduino sketch, I won't be able to do that because my Intel System Studio IoT edition only allows me to code in C, C++ or Java.

I initialize the UART with the following parameters:




and without flow control

Does this correspond to Nextion's UART parameters?

Oh, I also wanted to include that when my Nextion works with Nextion Editor through the USB to TTL Module, everything works as expected.

The unexplained 0xFFs appear when Nextion is connected directly to Edison's UART.

just make it easy ...

- connect Nextion via USB-TTL adapter to PC

- start a simple serial Terminalprogramm, which offers Hex view

- now just send out whatever command you like (for include FF FF FF, just create a Macro or copy/paste)

- and have a look what Nextion returns

most easy, and it shows the exact data byte by byte

if all works on this way as expected, it's time to digg in into your Edison code ...

not everything which is showed on MCU side must be result of a direct respond, it also can be a relict of a wrong or incomplete freed buffer in memory ...

I don't think, that the Nextion change its behave based on what's connected ... :-)

Ok so N81 is correct without flow control.

Apologies on the -1, (now the third known escapee from factory floor)

 - few out of so many,extremely rare condition, but apologies again.

Definitely could have been a possible contributor

But, I would think things should begin to work much better.

Now, you have a bit of digging in to do with technical documentation.

I never went the route of the Arduino Edison, but went much more bare.

(Mini Breakout boards, /sys/class/gpio, and Kylix3 pascal on soc over ssh)

Edison module IO is 1.8V, RX/TX on Nextion STM32 is 3.3V (5V tolerant)

Arduino version should be 3.3V/5V capable, shouldn't be a level issue.

You may want to check documentation just to ensure.

Regarding Intel System Studio IoT edition only allowing C, C++ and Java

The Arduino IDE I believe is independent from and wouldn't interfere with.

 - Arduino IDE has the Arduino Edison board available from menu

(I have not gone this route as I am at 1.8V logic ..., not an option for me)

but this is an option I feel is not intrusive, and may determine if communications stabilize.

Also, have you retested since you solved the -1 baud issue.  Results were?

Yes, I have retested, everything works fine (it even worked normally with the -1):

The factory test passed, my program also functions correctly (apart from the 0xFF issue).

My Edison does have 3.3V/5V IO and it's logic is identical to Nextion's.

Moreover, I'd like to highlight that Nextion executes all transmitted commands correctly and returns correct, expected replies. The thing is that every correct reply is accompanied by an 0xFF sequence which is generated by the preceding transmission.

For example:

I send con_nect.val=1 0xFF 0xFF 0xFF. The command is accepted and executed correctly. Then, I read the reply which Nextion returns using printh=60 00 00 00.

I do indeed receive this on RX but it is preceded by 40 0xFF bytes. These 0xFFs were sent by Nextion when I sent the first command.

And so on for every command.

Okay ... so if your command result is being properly sent by Nextion

And result IS inside the remaining returned ... the issue is

The preceding FFs are misinterpreted, read too soon of incoming serial.

Remember this is inverted logic, the line is high when idle.

This could be source reason for why you interpret preceeding 0xFFs

How are you determining byte arrived and buffer now has byte to read?

Just going through things to eliminate (pseudo code type examples)

It isn't enough to issue and then read until three 0xFFs arrive


     inbyte =

  until buf[i-2]=0xFF AND buf[i-1]=0xFF AND buf[i]=0xFF;

This could indeed read in phantom 0xFFs not there.

but should only be reading if and when the byte is in buffer


     if serial.available() then

        inbyte =;

  until buf[i-2]=0xFF AND buf[i-1]=0xFF AND buf[i]=0xFF;

Also possible if a function returns -1 as not there

 -1 converted to a byte is also an 0xFF as byte.

Somewhere there is a source of your 0xFFs

 - but it is not actually on the wire

I determine whether there is available data using the mraa_uart_data_available function.

I then read all of the data that has arrived.

The idea that these 0xFFs are return values of -1 doesn't make sense because the function I use does not return an error into the RX buffer that I allocate myself.

Login or Signup to post a comment