Start a new topic

It freeze under certain conditions

I purchased a Nextion 2.4" of recently and try to implement it in my project. But it turned out that I can easily freeze it tightly. I was able to do it more than once, or even twice. Every time I frequently push the button (or buttons) the Nextion freeze tightly and doesn't respond to commands, touch doesn't respond to pushing. This my exposure is non-standard user behavior, but this fact makes me refuse of usage Nextion in my projects.

Is anybody faced with similar problem? 

3 people have this problem

Any solution???

I tried to get support from manufacturer three times, but they are ignoring my attempts to find solution every time. They close ticket not even try to understand the problem.

One way to achieve reliably work of Nextion display is to be able to reset device when it freezes. There are unsoldered place for 5 pin socket (J2) on back side of PCB. It used for programming ST microcontroller. One of these pin is RESET. You can connect it to host microcontroller and toggle it to ground when nextion is freezing. One time in approximately three seconds send command for which you expect to receive a response. If no response got in timeout - reset device.

Another method to obtaining increased reliability is through understanding the processes that occur.

When a button is pressed, this triggers an touch pressed event and a touch release event to occur.  You state that your host microcontroller is waiting for a response from the Nextion Display, so I am going to assume that your event is defined to transmit data on the Tx line when the event occurs.

With a small and limited rx/tx buffer on the Nextion Display, rapid succession press events will overload that buffer quickly.  Various techniques can be applied to compensate.  I am reminded of the HTML submit button for payment processing, where rapid clicking caused several payment requests for the same order.  The solution was to disable the button in the first line of the event, carry through the rest of the event instructions, and then enable the button when the processing for the event has completed.  (Perhaps from the host microcontroller side) - thus preventing more press events than could (or should) be processed.

Before everyone starts soldering a hardware reset and voiding warranties, there are software commands to clear, and software commands to reset.

With regards to the closing of support tickets.  iTead has clearly stated in their FAQs what their support level is and that it is limited to ensuring that the hardware is functioning.  As this is clearly a matter of software implementation left up to the developer to decide what techniques they desire to deploy, it does not fall within the defined support level offered by iTead.  iTead does not support software implementation or work on debugging end user code.

I suppose in closing, doing some reading before jumping to conclusions may be a better approach.  It is also important to realize that in this embedded world, programming solutions becomes of more importance as the hardware has been provided in a more raw state to allow for many many solutions as opposed to being useful for only a given purpose.  That programming responsibility is ours not iTead.

> ... there are software commands to clear, and software commands to reset.

It doesn't react any software command after it freeze. There only harware reset helps.

With a small and limited rx/tx buffer on the Nextion Display ... will overload that buffer ...

Why this feature shoud provoke totally hanging of Nextion Display? If it is - it's not usable firmware. Any overload shouldn't hanging device.

Again programming and understanding.  The STM32 chip on the Nextion display that drives the HMI files has a small hardware buffer (I think it maybe 12 bytes, have to check the specs).  It is a circular buffer, so that when you toss 16 bytes at it without some of those bytes being clear (through the sending process), then the last bytes will actually catch up to the beginning of the buffer start and begin overwriting the first bytes.  Corrupted buffer.  Meanwhile functions that are in a hold pattern waiting until an ACK/NAK is received will do what they were told - continue to wait for that ACK/NAK. (I haven't checked the specs on this, and iTead has implemented TTL level reliability), so there is even more that the programmer has to be responsible for making sure the code on the host microcontroller checks.

> It doesn't react any software command after it freeze. There only harware reset helps.

Don't over load it to the point that it has become frozen.  This is within your control in the techniques you deploy, so that it never reaches that stage.  LOL.  It always amazes me, how desktop programmers have become so use to having everything done for them through years of library developments, and then faced with lower level MCUs, expect that all that was accomplished on a desktop is available in bare metal.  No, you actually have more responsibility to make sure that your input is correct for your purpose.  That a user has pressed characters that is a number before trying to convert it.  Some things are done in an Arduino style where many programmers have been daily working on trying to improve libraries, but that is not a guarantee that "your case" has yet to be coded, nor does relying on AS-IS Arduino code remove your responsibilities.

The firmware is extremely usable.  Consider that a bare MCU has a limited instruction set, and 16 registers and yet anything can be accomplished if those instructions are placed within the correct order - again up to the programmer.  The firmware is one example of instruction ordering by another programmer.  I can do many things with that firmware, but that doesn't mean that it is going to be as powerful as a desktop.  It only has 64K of flash, 8K of RAM and 4MB (2.4" version) of SPI Flash running at 48MHz and a 115200 baud rt/tx.  It is not expected to be a desktop.

So my belief is if you implemented a technique like only accepting one button press at a time, you would not end up in an overloaded crash state in the first place.  If you are purposefully pressing in rapid succession to overload the Hardware Interrupt Handlers via the resistive touch sensors, then being an idiot doesn't state the hardware is bad, it states that you have found the limit for which the highest number of events for the touch sensor can handle.  Again, the firmware allows for you to disable and enable touch, so you can also include those at the beginning and end of your processing routines.

I once pressed a key to put it in repeat mode at highest setting to see where the overload and limit was.  Doesn't mean keyboards are useless.  If your application truly requires that many successive presses, perhaps you should consider adding a device like a gamepad to your configuration and incorporate the additional devices necessary to achieve your goal.  That still doesn't negate the purpose of the Nextion.

> Any overload shouldn't hanging device.
It is NOT the hardware that is suppose to check for these overload situations.  If the next command were to be issued, could that be an overload (pause execution until such threat doesn't exist).  That is the programmers responsibility.  That is why commands like pause, and sleep for 10 ms exist.  To slow down the execution of the next command to allow for all other processing to complete before continuing.

They can be any number of design choices, and it isn't the hardware's fault the software designer choses to ignore all and expects all to be out of the box pre-configured to their specific purpose and already done for them.  You should probably avoid sensors, they come with even less pre-coded.

> LOL.  It always amazes me, how desktop programmers have become so use to having 

> everything done ...

I'm embedder, you shouldn't illustrate about tiny circular buffer. I try to employ the Nextion Display for my purpose and help you make workable device.

I even didn't use host controller. I create simple project in Nextion Editor, upload it, and applied supply. I press the button not so frequently (I can't provide 10 ms press period manualy), but it hanging. It hanging even I press the button one time in second. How can I to consider this firmware as usable?

I record video with this (and not only this) bug:

but support team (after 10 expectations days) answer that they can't open video and leave me with my problems alone.

I send to you a project file, no answer.

And you told me about "That is the programmers responsibility"?

I even didn't interact with your device, it hanging itself.

Lets find solution, don't make me an idiot.

iTead responses are from Support Team.

In the interests of finding a solution, can you post your HMI file here.  I have viewed your youtube video.

I will look at it with you.

Post both HMI and TFT files here if possible.

I will try to post corresponding files tomorrow, when I get to the work office. Thank you.

There is project files.

Windows 7 professional. v6.1(7600)

Nextion Editor v0.35

(134 KB)
(62.3 KB)

I am taking a look at your HMI now.  Can you describe what the screen is hoping to accomplish.  It appears like setting a time/timer value via the keypad?  What is suppose to happen next?

In sending all the Component IDs across the wire, can you give me the gist as to what is suppose to occur. Many cases, a lot of the math (no floating point available) can be done within the Nextion and then only necessary communications need to be sent across the RX/TX

I will help

There are 6 channel programmable timer. Automative and manual mode, separate program for each channel,

channels may be assigned as master or slave and so on...

I had built simple test page for insight of nextion functionality. This pattern of test page will not used in real device. And yes, it must had been time setup page.

But I noticed, that nextion display hanging while presing the buttons. I thought it due to the incorrect event buttons code. I delete all buttons events code, but it still hanging while button press.

Support recommends use text item instead integer item, but it do not solve hanging problem.

I didn't connect nextion with host controller yet, may be the answer on event packet is necessary for right functionality?

On this moment I plan don't use any nextion code, only buttons with release event packets to host. And text items which will be updated from host according to external or internal events.

P.S. I tried hanging "nextion 2.4 example firmware", I can't do it. But I can't compile it with Nextion v0.35 too. May be Nextion Editor generate incorrect code?

My thoughts lean partially with the serial ack not being answered if host not connected, and without the host connected - certainly overloading not only the buffer, but possibly the stack (depending on how iTead firmware was created).  Stack overflow would most certainly cause the crash.

Be aware that sometimes the HMI Editor may not necessarily clear all components/attributes when deleted.  In the past, a deleted page still retained space, possibly not entirely corrected and some incorrect code remains.  This has certainly improved over Editor versions, but no guarantee. Clean design in a new project file will perform better than design test file modified very often.

v36 has better driver in the firmware, better performance.

It is much easier to place a numberic or string variable in the page, have button presses modify the value, then place the value into the display text/number component for the visual purposes, but leave the final completely edited value to be sent with the button that commits to value - reduces Rx/Tx traffic and limits your host checking to only relevant matters that need to be dealt with.

Let me play around with this and provide an HMI example.  The HMI will deal with setting the timer values and have them available for use by the host.


Here is my HMI file for you.  It contains two pages.  The first lists the current values for six timers, and the second page is a user interface to set the timers.  It will certainly not contain everything needed for your entire project, but will give you some examples of techniques I used to address some of the issues:

1) disable/enable touch while routines are busy.

2) reduce rx/tx traffic

3) use one page for data entry rather than one for each timer.

4) handle time input in a format easy for human understanding

5) provide time for host in a format easy for machine manipulation

Initializing the timers when the host starts up is easy.  For each of the six timers, utimer1 to utimer2, set the .val attribute to the value of minutes in the day with a serial.write from host
and when all timers needed to be initialized are completed send from host
Serial.Write('page 0')
with a space between page and 0, which will refresh the page and format the timers in an HH:MM format.

Rather than having several pages for entering a time, you have one page for data entry.

In this page, the minute in day (range 0..1439) is out into HH:MM format, transferred from the main page.  the "x" upper right will cancel without any changes made.  0 through 9 will append the digit to the end of the value, while any fifth digit will be lost.  The "<" will backspace and will left fill with zeros.  In this manner, 12:45 can be attained both by 127<45 or by 1271245.  The touch is disabled during this time preventing overloading, and re-enabled at the end of the functions. 

Before ending the digit the value is checked setting the input to red if invalid, or green if valid, allowing the user to be aware if the value is acceptable or more entry is needed.  Finally the E will confirm entry is valid and if it is, set the utimer value to the new value, returning to page0 and update the timer list.

It is noteworthy that all the calculations are performed on the Nextion within the HMI.  The only event that needs to be captured is that one of the timers has been changed by the user.  This can be accomplished by setting the E button to Send Component ID (if the host is going to be connected - not currently set to avoid overloading) inside the E Button's Touch Release Event.

This will send the message 0x65 0x01 0x0C 0x00 0xFF 0xFF 0xFF to the host over Rx/Tx, where 65 is a touch event, the 01 is from Page1 the 0C says component 12, 00 says touch released and FF FF FF denotes end of message terminator.  You host now knows a timer was set, but which one? to what?

Within the same block as receiving the message send

Serial.Write('get sys0')
This will be returned with a numeric value message 0x71 0x06 0x00 0x00 0x00 0xFF 0xFF 0xFF


The 71 tells you a 32 bit number follows, LSB to MSB. 06 00 00 00 (hex) - equates to 6. The FF FF FF again is the data message terminator.  Timer6 changed, so next send

Serial.Write('get utimer6.val')

This again will be returned with a numeric value message 0x71 0x29 0x04 0x00 0x00 0xFF 0xFF 0xFF


The 71 tells you a 32 bit number follows, LSB to MSB. 29 04 00 00 (hex) - equates to 1065.  The FF FF FF again is the message terminator.

Timer6 was set to minute_in_day of 1065.  A nice format for machines.

1065/1440 is 0.7395833 of a day

1065/1440*24 is 17.75 (or 17:45)

easy to set for next day, calculating between dates and times, etc.

So attached is the HMI.  I hope the code examples help.  As for presses crashing, all has been done that I can think of to prevent it (using tsw 255,0 to disable tsw 255,1 to re-enable).

Let me know how it works out.

(71.6 KB)

1 person likes this