Start a new topic
Not Taken

Firmware update protocol

I think a more robust firmware update would be a nice addition to the Nextion LCDs.


  • User initializes hmi upload protocol
  • User send 4096 byte packet + CRC checksum
  • Nextion responds 0x05 for good data 0x0A to request packet again
  • After completion of upload, Nextion reboots

As well, it would be great if the customer had the option to enable redundant code space. This would allow for the screen to fall back to the current firmware if the update fails. This would reduce available code space but a sacrifice to make to have a failsafe screen update. 

Nextion displays, including the Nextion Editor is CLOSED SOURCE. Publishing any reverse engineered part MAY harm IP rights and should be handled with care ...

The last 4 bytes of *.tft and *.HMI files appear to be some sort of checksum bytes. Does anyone know the algorithm that computes these bytes?

As the original request is to 1/2 SPI space for dual TFT space - not taken

I am now reviewing all of the Feature Requests, this will take some time, patience please.

Although this wasn't a real feature request, it is now marked as reviewed.

Yes it is :)

Hello Patrick.

Is your e-mail‎

I know that there have been some PIC discussions in the Free Chat section ...300+ threads, I wish there was a quick way to search them.  I might eventually build a utility for such.

Are you certain that module is too big?  As the pins out are 0.1" spaced I am betting it is ~ 1.5"x0.75"

I have personally have raw sockets, but the are certainly hell to attempt to solder, 1 in 5 success rate.

Another option is the SPI Flash Winbond 16MB chips.  These certainly increase space from 1K to 16MB, but I would have to look up the PIC specs to see what kind of SRAM it has and if it has hardware SPI like the STM32 or if it has to be bit banged with serial SPI.  The SPI Flash chips are much easer to solder.

Also as for size - there is a difference between "development" when you are testing if you need capacitors and resistors on pins and the final result.  While developing and testing it is more like an open surgery and everything is out on various tables.  Size doesn't really matter at this point until you get things right.  When it is right and your design is perfected - then a place like Itead could build custom PCB boards for you.  That part can add a lot of expense and you don't want to have many copies of a wrong design, which is why protoboards and larger modules one can handle with their fingers are used first - until we know.

Hello Patrick.

Thanks for the good advice. Unit on link is to big for me.

It must have space on the bottom of Nextion 3.2" or 2.4" Not go outside and have thin form.

Ideally I will use Has extensive experience with programming interface for midi-accordion in C.

I've use WIZ-C from Fored Electronic a very good software for program Microchip microcontrollers in C. Where I have several ways to store/load user data. Have not tried connect the Nextion TFT to the Pic18F.

Is it someone who uses PIC18 and maybe have a simple example?


Here is an example an microSD module for Arduino on eBay ~ $1.00 USD

The source for such a module and which libraries depends upon which MCU you choose to use.

One very important key to success is reading, and more reading before trying to fry MCUs.

For most electronics there are manuals for each and every chip.  And these manuals are important.

As an example the Winbond SPI flash chip manual is ~100 pages.  The STM32F103 91 pages for the Product descriptions (pins and alt functions), 156 pages for the Programming Manual, another 1137 pages for the Reference Manual and ~ 500 pages for the Definitive Guide book for the Cortex M3.  The specifications for the TFT screens are around another 233.

Now contrary to the book title that says learn C++ in 21 days, there is certainly more to it that.  Choosing which language you are going to program your MCU with and then learning the inner details of that compiler takes time.  Skipping from one compiler to another only allows you to skim and never master.  But the journey has to start somewhere.  Personally, I chose pascal and not Arduino.

One beauty of Arduino is that it allows people to begin with small steps, with moveable wires as opposed to fine detail soldering.  There are plenty of "Kits" that allow a person to go through various sensors, and in doing these excerises, one begins to get exposed to communications for UART, SPI, I2C etc to be able to have their MCUs talk to these other chips.  The Nextion uses RX/TX over TTL a sort of watered down version of UART or serial communications.  Wikipedia, Arduino and Google are good sources for digging for more information.

And then we are back to the programming aspect - you have to strategize all these things that are going to be going on between your MCU, the sensors it is going to connect to and the Nextion display where you are going to interact with the user though showing them the information they need to make choices with and the touch panel where the user makes their choice.  Most of this begins with playing around in the Nextion Editor and seeing what is possible or not possible.

Which MCUs, model Nextions have you chosen and what are you attempting to do in your project?

Hello Patrik.

Can you help me with that? I'm new with Arduino and Nexrion. Can pay you for the job.

The neat thing Per is that you could connect an SD card to your MCU as well.

1 person likes this

If ITEAD had expanded the SD card for save/load user data, so not any problem!

I would think any attempt would kill the warranty.  The eeprom would have to have the exact  same instruction set as what is on the Enhanced Display as the Nextion firmware can not be changed.  On the off shot that it was successfully transplanted, if the firmware checks to ensure that the address does not exceed 1K, there would be no way to circumvent the firmware.  A transplant with no results.

Is it possible to change the I2C eeprom to 24LC256 for Enhanced Nextion display? 1024 bytes is too small for my applications.

Patrick, thanks for the detailed response. The method of using a local flash is what we are considering for a future spin on our control board. We are currently validating the data received by the MCU is correct and then sending to the Nextion.

For the backup version, we envisioned it would be implemented such that you always try to overwrite the oldest version or corrupt slot. Nextion starts with V1 in slot 1. Updates continue on slot 2 until valid update. Only once valid you now write to slot 1 next. This is the method we have used successfully with past programs.

I agree that the best solution would be to handle everything on our control board with added flash and a local copy of the tft.

Login or Signup to post a comment