I think a more robust firmware update would be a nice addition to the Nextion LCDs.
The upload protocol was published to allow commercial clients the ability to control their updates. I am failing to see the issue with the redundant code space. With the upload protocol in hand, are you are not now capable of developing this as you see fit.
I think it is great they documented the protocol but there are still challenges for spaces where customers are involved. In our application, the only user interface to the device is through the display and say the update gets interrupted part way through a firmware update (ie power failure, loss of internet where the file is being pulled from, etc.) then the device is "bricked" in the eyes of most customers.
If the firmware update fails, the display only shows "DATA ERROR!" and when it boots with or without good firmware it currently send 00 00 00 00 FF FF FF 88 FF FF FF. We could have our controller request data from the display, not receive it, and infer the file is bad but ideally we wouldn't have to do this.
If there was redundant space, we could alert the customer "Sorry, it appears the last try to update failed. Version X.X.X is available, would you like to install? <Yes> <No>".
Perhaps this can already be accomplished via the connecting MCU.
Users complain about limited HMI space now, so with such a reservation for a previous edition the HMI space would be a maximum of half the flash space now. For 4M flash users, this amounts to now under 2M of HMI space and 2M for previous version.
Yet on the connecting MCU, the amount of flash you add to your device or via an SD card is far greater than what is on the Nextion display. (1GB microSD and you have space for almost every version).
The MCU should be checking first (by CRC or other digest) whether the new firmware has arrived intact before attempting to upload to the Nextion display. If this means download via the Internet and confirming it has arrived to the MCU intact first then this is extremely important. But you wouldn't even initiate an update if there were any uncertainties of it not being able to be completed - as you pointed out, your customer would consider it bricked.
The flaw in the logic for "backup on device" is that the backup would have to be static at best - a version 1 of your HMI. So version 2 rolls out, version 3, version 19 and your backup is still at version 1.
As soon as you attempt to update the backup version 1 to version 2, you have initiated the same concerns that you stated why you are reluctant to initiate an upgrade without a backup safety net. The in device current version begins to copy to the backup slot, some error occurs and there is neither a current firmware nor a backup. Whether it is half or all of the flash that is being upgraded, the same obstacle has to be overcome.
This is the reasons why CRCs were invented, as some sort of assurance that the data received over lossy lines could be considered relatively reliable. The store and forward method to download the software first, verify that it is correct before installing is amongst Best Practices (happens everytime you download software for your computer - including the Nextion Editor setup). If CRCs do not provide enough confidence, then other hashes such as MD5 and SHA1 are tuned to a finer degree of assurance.
Having a backup located in a flash or microSD on your MCU allows you to reinitiate the Upgrade, so even if an upgrade were to fail, your MCU already knows the procedure for upgrading, it is merely a matter of attempting the upgrade a second time. This makes the point of failure solely whether or not the file to upgrade to is reliable and we are back to CRCs and digests.
Depending on how distrusting you are of the communication signal, the old school method was to break the communication into chunks. (perhaps 4K is small enough as per the protocol). Comparing the CRCs will let you know in regular intervals as per the ongoing success of the upgrade and alert your software if the upgrade will need to be redone. I see no reason why if an upgrade fails at 75% why the upgrade couldn't be reinitiated at the end of the failed attempt and within the same session. As to the user experience, the update took longer, but was necessary to avoid bricking - so acceptable.
From the point of retrieval, the tft file and its calculated digest (crc, md5, sha1) should be stored.
Retrieve your tft file, calculate the digest for the local copy just downloaded
Retrieve the point of retrieval digest
Compare the two digests
- if the digests are not equal, you would not initiate the upgrade - but you might reinitiate the download
- if the digests are equal the download is a success - proceed to upgrade
As per the protocol, the tft file is to be sent to the Nextion 4K chunks + partial 4K for last chunk
- after sending 4096 bytes there is a delay of ~ 0.5 seconds for the ack byte 0x05.
- if this byte is not received after 1 second, you know which chunk your upgrade has failed on.
If your MCU has a copy of the last known good version and the upgrade failed
- you have the abiltity to reattempt the upgrade (to a max count as decided by you)
- you have confirmation that the download was successfully received
- if max count was reached, you have the last known good working version
Revert to upgrading the last known good version
- the user is left with the same version they had before the upgrade was initiated.
- again if failure occurs - reattempt until max count
(If it fails at this point there is probably a real failure with the device that really needs to be looked at)
If the upgrade is successful, record that the upgraded version is to be used as last known good version
You might be surprised that in a standard computer system, the max count for retrieving data from a hard drive is 5. It can fail the first four attempts and still not be considered a failure - the user will never know except for very small decrease in speed for a split second. It isn't considered a failure until it has failed 5 successive attempts. These type of techniques are what makes applications robust.
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.
Is it possible to change the I2C eeprom to 24LC256 for Enhanced Nextion display?
1024 bytes is too small for my applications.
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.
If ITEAD had expanded the SD card for save/load user data, so not any problem!
The neat thing Per is that you could connect an SD card to your MCU as well.
Can you help me with that? I'm new with Arduino and Nexrion. Can pay you for the job.
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?
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 Pic18F.xxx. 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?
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.
Is your e-mail firstname.lastname@example.org.