Existing Working Deployed Nextion Projects not working since past two weeks

Hello Guys,
We are a small company that has been working with Nextion displays quite extensively for our projects for the past one year and we have sold more than 30 displays which worked flawlessly until recently!

We pushed out an update recently with fresh compiled TFTs and since then all our displays have stopped responding to hardware! Compiling previous versions which were deployed aren’t working as well!

We suspected the new update 1.63.1 and 1.62.1 but compiling with 1.61.1 after uninstalling the updates haven’t helped as well! We have fresh stock of 4 displays with us and neither respond to our arduino based hardware however connecting the same microcontroller board to nextion debugger works flawlessly! The debugger responds correctly.

We have enough experience with the displays and we have checked baudrates / serial ports etc so that’s not the problem for sure.

Nextion debugger + our card = works
Nextion Display + our card = used to work 2 weeks ago, doesn’t anymore

Any idea what’s going on? Any work around?

1 Like

Hi and welcome!

Me and a few other people experienced something similar, though you’re the first one where a rollback to v1.61.x hasn’t helped. The thing is, 1.62.x has made the devices much more sensitive to power supply issues. Therefore I’d recommend to check that. I made a detailed post about my own case here (symptoms are described a few posts above): New Nextion Editor 1.62.1 is available - #9 by Max

Hope it helps!
Max

1 Like

Hey Max!
Great to hear from you and thank you for the welcome!
I totally forgot to mention that I had already seen your post and I did try the capacitor approach but it hasn’t solved our problem!

You mentioned that serial is a hit and miss, well ours is just missing! Not even a single function working currently and the support from the distributor and Nextion is just terrible! They simply point fingers on each other for the required support.

Any other leads I can try with? We have tried installing a completely fresh 1.61.x on a fresh computer and nothing!

I use 70+ Nextions per year in a side hustle project.

With that and other projects, I have programmed over a dozen different screens, (of various sizes 3.2, 3.5, & 5.0", both Basic and Enhanced) in the last few weeks with the latest Editor version without any drama. Every screen has behaved correctly, with no inkling of any problem.

All the screens prompted “Firmware will be upgraded”, as some of the stock was programmed weeks ago with 1.62.x, and some were fresh out of the box.

I always upload @ 921k (the fastest rate) via a USB-FTDI adapter.

Have also programmed some TJC T135 variant screens with the latest USART Editor v.63.1.
Again, no issues encountered.

I just haven’t seen any evidence that 1.63 has any affect over reliability of serial comms or requires more stringent requirements of power supply rails during programming or running in the final application.

This doesn’t help you of course, but perhaps a closer look at your power rails?

Do we assume you are using the standard 4-way interface cable that is supplied, and that you haven’t extended it.

A mate of mine was having EMC issues with the 5.0" Enhanced (these are really grotty with spurs extending all the way up into VHF due to the backlight PWM) and extended the 4 wire interface to accommodate multiple turns around a ferrite. Doing that caused intermittent operation as the screen was talking to the MCU @ 115k.

I suggested he return the TXD and RXD lines back to normal length (and not within the ferrite which would tend to attenuate higher frequencies - which is their job!) and leave the +5 and GND wires to run through the ferrite. His problem was fixed.

What I noticed with my screen is sort of a degeneration. When I first upgraded to 1.62.1 there were no issues. They only appeared after a couple more flashes. The capacitor has fixed it for most of the time but on some days the screen still won’t start (stay black and/or flicker) and I need to use a separate supply for the screen instead of the USB port I normally use.
This kinda makes sense in my case because if you have a closer look at my scope shots in the other post, the 3.3V regulator has 0 margin. Even the tiniest negative ripple on the 5-ish volt rail goes straight to the 3.3V rail. Most of the time that’s fine but sometimes it’s not - and apparently that “degeneration” continues; more and more often do I have to take a separate supply.

The point of the story is, don’t just put a cap on the screen, do measure the rails with a scope if you can. If you don’t have a scope, take a 5.5V or even 6V supply to make 100% sure the crappy* 3.3V regulator has enough margin to actually regulate and check it again.
*on my screen it’s an AMS1117 3.3V which has a dropout voltage of 1.1V typical and 1.3V max. For a USB powered device I do consider that as a crappy choice. The USB standard actually says USB powered devices like this one should operate down to 4.4V => Nextion is not compliant with it’s 4.75Vmin spec even though it suggests this by delivering a USB adapter with the screen. A quick search on LCSC lead to the SE5120 series of regulators (3.3V version: SE5120ST33). Pretty much same price, same package and pinout, better current rating and only 0.3V dropout voltage. I’ll probably replace the regulator on my screen with this one or something similar.

Oh one last detail you didn’t mention… how exactly did you downgrade the devices back to 1.61.x? SD card?

Kind regards,
Max

1 Like

I’ll put the supply on a scope and report back but also I updated the programs using SD card

Hey Max!

So we tried with USB uploads and TFT uploads both and yet no difference!
We normally use 115200 as a baudrate between our controller and the Display.

One more observation is that we use the ITEAD Nextion Library and it isn’t working but we were reccomended to use the EASY NEXTION LIBRARY found here - GitHub - Seithan/EasyNextionLibrary: A simple library for Nextion display that uses only four functions. You can easily benefit from Nextion's wide range of features and advantages in just a few easy steps. The library uses a custom protocol that can prove to be a powerful tool for advanced users as it can be easily modified to meet one’s needs.
and with a few tests we can see that this library works on basic codes! we just haven’t been able to test this with our complete codes as that would take a long time for us to modify!

Can you help me find out why the ITEAD library won’t work anymore? I can then try to fix that. Also testing this new library with a more extensive application is yet pending and we’re working on it, I’ll update if it works for extensive applications as well

Okay if serial upload works fine I‘d rule out power supply issues for the time being.

I never used the official library; the stuff is so simple I implemented what I needed on my own. Tbh I wouldn‘t want to debug their library. Not my or your job. You use libraries to not have to mess with those issues.
I don‘t know the other library either so I can‘t tell you whether it‘s well-written or not. But if it is and fullfills your needs, why not?

Kind regards,
Max

I am having no problems with the new update. I am only running at 2400 baud as my inverters run at this rate . Why do you need such a high baud rate , can you try a lower rate. Also I have my code running on the nextion itself there are 19 variables and 9 timers on one screen doing animation , sending requests to inverter , reading the serial buffer , parsing the code from the buffer and a number of other things. Note using a 7 inch enhanced. Running power from a asus notepad charger volts are 4.93. I also only use the SD card to load the screen.

If you’re doing a production product then I highly recommend skipping all software updates. Once you go to production you should essentially freeze your development tools and back them up remotely just in case. This gives you a known working development environment for future production as well as the ability to service existing product. Having a production product with a mix of firmwares and programming tools is asking for headaches and added complexity.

Regarding your current issue. Try to flash an earlier compiled binary to the displays. Simply installing the older IDE and recompiling adds an additional variables.

Use a USB-Serial adapter to connect a faulty display to the Nextion software. Try to upload new software set the uploader to auto detect the display. The Nextion uploader takes a couple extra steps into ensure communication to a connected display (scanning baud rates, sending commands to end protocol reparse operations, etc). If the loader can communicate with the display then you have something to work with.
Next, try using the debugger (simulator) software tool to communicate with the screen manually using simply serial commands. Try something like, “cls RED” followed by a delay and see if the screen responds by turning red.

I would also try sending the command “dims=0”. This will set the screen brightness to zero and save this value for future power ups. I don’t have the exact numbers handy at the moment but reducing the backlight from 100 to 0 substantially reduces current draw. If you are having power related issues then this will reduce the startup current and help maintain sufficient voltage levels during the important period immediately after power up. If you can flash new code to the display then you might also try placing the display in a sleep state immediately upon power up to further reduce voltage dropout and then waiting briefly for the power to stabilize before waking the display up and increasing the backlight levels for normal use.

Another thought, grab a previously compiled bin file and use a hex editor to compare it to a newly recompiled version of the same program code using the previous IDE. If the files are identical then it suggest the firmware on the display might have been modified by the newer software. I know some updates in the past have made changes to the firmware on displays that break compatibility with earlier Nextion software and make rolling back to the previous firmware/IDE very difficult.

The last thing to check would be using a logic analyzer capable of analog readings to sniff the power and RX/TX lines. You should see a smooth power up without voltage dropping out followed by serial communications in the RX/TX lines. If these serial signals are absent then you have a low level issue that’s halting the party during the initialization and startup processes. Look to see if the signals on the RX and TX lines clean and try to determine if the display is responding to incoming commands and if the microcontroller is accurately receiving responses from the display.

Hope this helps out. Good luck!

Hey Max,
So we had success porting out our old projects to the new library I mentioned above but the funny thing is, the problem we faced with the old libraries or editor (I honestly don’t know yet what caused it) has fixed itself ! Old programs and everything just work perfectly fine now! Very weird but I still don’t have a clue what happened exactly! We found out when one of our customers didn’t report to us that their system had stopped working with the last update, then they went on to flash the same file after a month(I assume their machines were not in use anymore) and the machine just started working again! I got to know about this yesterday when I had a call with them :confused:

1 Like

Hey paulvk!
Our displays have around 96 analog parameters, some whole numbers and some floats that need to be updated at 1hz and we have found that lower baud rate slows the entire system by quite a lot when we try to update so many parameters at once! Last project I worked with had 20 elements update on two different graphs at 1hz and even that was a stretch at 9600, hence 115200 :slight_smile:
Thanks for your response !

Amazing tip! I am definitely adding this to our SOP

Thank you Ratnin for your response but I think I am done debugging the displays since they’re working correctly now! But I hope this helps someone else!

I am now going to follow your tip and only deliver the .tft files to our customers as updates :slight_smile:

“Our displays have around 96 analog parameters”
My inverters send 26 blocks of data with a “(” as a start character , space as delimiter and cr/lf as end I use the reparse mode as this is sent in a known order the nextion then sorts this out and assigns it to the variables so all that is sent is the data no variable names.
Note at the end is a xmodem crc so data integrity can be checked and when a command is sent to the inverter the xmodem 16 crc is also worked out and attached.
Also some numbers can be a negative value this is handled by putting the value in a location in the data which represents it as negative and the positive location is set zero as both can be zero as this represents battery charge/discharge the nextion see both as zero then just places a zero in the number value , if the negative position has a value greater than zero nextion then shows it as negative.