Developing HMI projects

A way around these “oops” moments

It’s hot outside. If you are lucky, you have air condition. I haven’t. I live in a more than 400 years old house in France. But with air condition or without, everyone who writes Nextion code has already experienced this:

You sit in front of your computer, you work on your ultimate HMI project, you compile it without errors, it works well in the simulator, you decide to upload it onto your Nextion HMI display, it reboots and you find it either showing a black screen or unresponsive (bricked). That’s one of these “oops” moments. You reboot it again, but without noticeable change. It seems dead. What to do?

From my years long experience, I want to share some “highlights” as seen in my own work, in user forums, and our support system. I’ll explain how these can happen, and show at the end how many of these can be fixed and your precious Nextion HMI display recovered.

System variables – A curse and a blessing

Nextion system variables are a great thing since they allow to change easily some system-wide settings, sometimes even in a persistent way. That means that these new settings might “survive” a reboot or a power failure. That makes it naturally impossible to recover your screen easily. At the very end of this article, I’ll show a way to get your screen working again. But before, let’s look at some famous traps:

Screen brightness

You know for sure that there are 2 system variables to control the screen brightness: dim and dims. With dim=xx, you set the current screen brightness by replacing xx by a number between 0 and 100. So far, so good. With dims=yy, you set the new default screen brightness at boot time. If this command was inadvertently issued with yy=0, it might be that your HMI project runs perfectly, but you aren’t aware of it because the screen remains black, even after reboot.

Baud rate settings

Your local code (in Nextion language) works well, the screen shoes what it has to, but your Nextion HMI doesn’t seem to communicate with your MCU or, worse,  with the simulator/debugger running on your PC via a TTL serial to USB adapter. If it’s only a problem with the MCU, odds are good that you can use the auto connect function of the simulator to have control over your HMI again, and to see from this to which baud rate it has been (perhaps inadvertently) set. Remember, baud=xx sets the current baud rate, while bauds=yy sets the new default baud rate at reboot. Thus, if for whatever reason, the Nextion’s baud rate is set to 921600 and your Arduino is workin with 14400 baud over software serial, the misunderstanding is preprogrammed.

Things can get worse. You might have set the baud rate to 31250 because you’ve read one of my previous articles about the upcoming Nextion MIDI I/O interface or to 250000 because you are thinking that after MIDI, the Nextion guys will probably care about DMX (and you are right). Both baud rates are not supported by TTL serial to USB adapters based on the CP2102 IC which is for example used in the Nextion Foca Max adapter and many others. Thus, the method above won’t help. But nothing is lost, I’ll show at the end how to bring it back to a more standardized baud rate. Please re-read my MIDI-related posts and look at the example projects. These are made i a way that the Nextion’s default baud rate is never modified, and you can always control it latest after a reboot, since extra user action is required to switch temporarily to the MIDI baud rate.

Protocol mode

The screen displays something, your Arduino gets data over serial from the Nextion, but no way to send commands like, for example, page0.n2.val=375 from the MCU to the Nextion? Reboot doesn’t help? Your Nextion code switches the screen probably and unconditionally into the active protocol mode during startup. Modify your code in a way that protocol mode is always passive by default and set it only to active when needed and return immediately afterwards. The corresponding system variable is recmod. recmod=0 is the (default) passive mode, recmod=1 the active mode.

Address mode

Although serial connections are simple point to point connections, Nextion’s address mode allows the use of several screens on one single MCU using address mode. Each screen must then have a different address between 256 and 2815, set by  addr=xxxx. In that case, your screen will only accept those commands sent over serial which are prefixed by the corresponding 2 bytes. To disable the (seldom used) address mode, your code must set addr=0.

Sleep mode

Allowed your Nextion to sleep with sleep=1, ussp=xx, or thsp=yy and forgot to allow it to wake up by placing  sleep=0 somewhere in your code ? Continue reading, the solution is close.

The solution

Solving all problems cited above and many more can be done with a Rescue SD Card. Even if your Nextion does not longer accept commands or firmware updates over serial, odds are good that it will read from an inserted SD card on boot which contains just some code to reset the most important and probably blocking system variables to their default values. Once your Nextion recovered, you may fix your HMI code and compile + upload it again.

How to create the Rescue SD card ?
  • Start the Nextion Editor
  • Create a new HMI project via File -> New
  • Name it empty.HMI and save it.
  • In the “Setting” dialog, select your screen model and size, 0° orientation, and an uncomplicated character encoding like ascii
  • Move over to the program.s tab. We only add code, no visual components.
  • Add the code lines as follows (added lines are shown in bold)
//The following code is only run once when power on, and is generally used for global variable definition and power on initialization data
int sys0=0,sys1=0,sys2=0     //At present, the definition of global variable only supports 4-byte signed integer (int), and other types of global quantity declaration are not supported. If you want to use string type, you can use variable control in the page to implement
// restore some default values:
dims=100
bauds=9600
recmod=0
addr=0
sleep=0
page 0                       //Power on start page 0
  • Now, go to File -> TFT file output. Click on “Output”. This will compile your code into a empty.tft file, open the Explorer and show you the result.
  • Copy the compiled file over to a FAT32 formatted Micro SD card.
  • Put this SD card into your Nextion’s slot and power cycle.
  • You are done, your Nextion is alive and responsive again.

Happy Nextioning!