Start a new topic
Solved

Problems with new version of NX3224K028

I think there is a problem in the new version of the NX3224K028 nextion display.

I ordered some displays a few months ago. I use the command "rept 10,10" over serial line to read out 10 bytes of the internal EEPROM memory. Everything was okay, the command finished successfully.

I ordered a new batch of displays a few days ago. I received a new model with the same article number but different pcb layout. The behaviour of the displays is not the same as with the old ones. When I use the command "rept 10,10" I can't read out the EEPROM values. I used delays between the commands -> same behaviour. The only way to get out the EEPROM values was to send the command a second time. The first time always fails, every further 'rept' command is okay.


I have a few questions about this issue:


- Is there anybody else who can confirm this behaviour?

- What is the reason for the new pcb layout?

- Is there any new firmware in the newer version of the display?


Best regards

Matthias



the Nextion firmware needs to be initialized at startup with a single sequence of "ÿÿÿ" ...

unfortunately, based on which commands have been executed, the STM changes internal global registers. To make such global changes visible for the firmware again, all must be reinitialized with a"ÿÿÿ" sequence first ...

if you don't track most carefullt about the real state of your display, your external logic has no real information about the initialization status of your display ...

therefore, the initial "ÿÿÿ" is maybe missing, that's why a first send rept won't work ... the trailing "ÿÿÿ" is not used to trail the command itself, it is used as reinitialization sequence for further commands. That's why the 2. time the rept works ...

This behave is already reported a few times ...

The save way to issue a command is not sending

    - "rept 0,255ÿÿÿ"

but sending in general

    - "ÿÿÿrept 0,255ÿÿÿ"


This 3 bytes more in communication for leading "ÿÿÿ" are just a save way to make sure that really every send command is executed.

leading and trailing "ÿÿÿ" for every send command are the save way ...

 


PCB layout can change to many resons, EOL of used parts, better available parts, ...

Firmware is part of the TFT file and updated by ... newer versions of Editor also means different version of display firmware ...

To track the state of the Nextion device

   refer to the Nextion Instruction Set

       Format of Device Return Data


Users not reading the Documentation does not make it a bug.

Not understanding the Documentation does not make it a bug.


Questions for understandings should really be made in Free Chat

   rather than make it seem Nextion has 300+ problem issues


Waiting for Nextion's response before sending next command is also a reliable means of working with nextion as well as using such return data for debugging and understandings.

I have tried to test the solution with the prefix '0xFF 0xFF 0xFF'. But it doesn't work. The behaviour of the display is the same. The prefix doesn't change anything when I send any other instructions to the nextion. But for the first 'rept' instruction it doesn't work with the new pcb layout.


By the way: I use Nextion Editor V0.47 for creating the TFT file.



@Gerry:

Thanks for your detailed explanation.


@Patrick:

Yes I have read the instruction set of the nextion display. The problem first appeared with the new pcb layout. I have installed about 30 pieces of the old ones. They don't make any problems with the same instructions and the same TFT file. So could it be only a code problem?



I will circle back to what I referred to about Nextion Instruction Set.


So what you present

 - All 30+ displays, the same vendor?  months apart in two batches.

 - all of the second batch (qty?) are of the new kind?

 - all installations were version v0.47 built TFT files

 - no changes to TFT from first installed to last installed

 - MCU side code and component configuration had no changes


Indeed only when all other besides the PCB remained constant

  can you draw a conclusion issue maybe the PCB

(PCB can be a contributing factor, but other factors also contribute)


version v0.47 was not available 3 months ago (v0.42/v0.43 ish), so is

    meaning first batch sat on shelf during development until installation

    which only happed within the last week(s)?


So your vendor is ...

Display in question cross tested with different MCU to eliminate MCU?

Any details about MCU used, compiler versions used?  Which compiler?


What is the state of the Nextion system variable bkcmd at time of repo

Circumstances of repo - is it the first command on start?  where placed?

Which Nextion Data Return codes are actively monitored and acted on?


I try to answer all the questions:


 - All 30+ displays, the same vendor?  months apart in two batches.

I got the 30 Displays in two batches, but from same vendor. The newer ones are from same vendor.


 - all of the second batch (qty?) are of the new kind?

the qty. is 16 pieces


 - all installations were version v0.47 built TFT files

all displays has been updated with v0.47


 - no changes to TFT from first installed to last installed

I changed some contents in TFT, but updated all Displays at the same time with v0.47.


 - MCU side code and component configuration had no changes

MCU code was the same, same wiring, ...


Indeed only when all other besides the PCB remained constant

  can you draw a conclusion issue maybe the PCB

(PCB can be a contributing factor, but other factors also contribute)

As I mentioned before everything is the same, only display is a newer one.


version v0.47 was not available 3 months ago (v0.42/v0.43 ish), so is

    meaning first batch sat on shelf during development until installation

    which only happed within the last week(s)?

I used different Versions of the Nextion Editor. But now I only use v0.47. All the displays has been updated with this version v0.47. I use the upload function of the software in conjuction with a FTDI USB-Serial converter.


So your vendor is ...

Komputer.de


Display in question cross tested with different MCU to eliminate MCU?

I tested several Displays with several CPU boards. The result is always the same.


Any details about MCU used, compiler versions used?  Which compiler?

MCU is ESP32 (Sparkfun ESP32Thing), Compiler is Eclipse CPP neon.3 Release 4.6.3


What is the state of the Nextion system variable bkcmd at time of repo

I don't have checked it yet. I will check it the next few days.


Circumstances of repo - is it the first command on start?  where placed?

There are different instructions before the rept instruction. Every instruction before is executed okay.


Which Nextion Data Return codes are actively monitored and acted on?

Most of instructions are send without analizing the anwer of the display.



Thanks, helps a bit for better understanding.

  - better understanding might help provide you with a better answer.


So indeed there will be some changes when Editor versions change.

  - this you would have noticed when updating the older versions to v0.47

  - updating of various "drivers" occurs on version changes that do not

    occur when within the same editor version, user message is displayed

    to the Nextion screen when this occurs.

  - the bulk of firmware is contained within the compiled TFT being uploaded.


There may even be some new timings caused by

  - changes to MCU code

  - changes to the HMI design

  - combinations of instructions

  - any differences in any different components between PCB boards.


But the firmware is going to operate in the same manner.

  - instruction loaded/received

  - instruction interpreted

  - instruction executed

  - Nextion Data Return code sent if system variables set to do so


The rept command is of a few commands in a class that uses external

    resources (the eeprom) as compared with internal

  - as such there is additional timing needed to established connection

  - the timing could indeed be varied for first compared to subsequent uses


But I will indeed argue 

  - changing Editor versions will indeed be expected to have behaviour change

  - change in PCB design will certainly be suspect to have behaviour change


Nextion Data Return codes are also there for performing debugging

  - an assumed timing - assumptions can work, but also may not

  - certainty comes from using the Return Data and even debug type print/printh

  - Not analyzing the answers of the display - I will advocate is less than correct

    because in these Data Return Codes becomes your timings, at the very least

    to see if and how much delay is required for a circumstance

  - when this is known, code adjustments can be made and then after knowing

    perhaps return to a shortcut method of not analyzing Nextions answers.


Assumptions create issues

  - but Nextion is indeed sequential processing and will certainly not start a new

    instruction until the old one has been completed. 

  - And it is indeed possible to see when such instruction has ended and inform 

    your MCU that it has completed using the Nextion Instruction Set.


Skipping such because it is convenient does not make it a Nextion BUG 

I debugged the responses of the display. In the critical path (first rept instruction) there was a response like this:

0x00 0x00 0x00 0x00 0x00 0x00 0x88 0x00 0x00


The instruction manual says:


0X88 System successful start up This data is sent after a successful power-on initialization on the device


I increased the delay between the 'rest' instruction and the 'rept' instruction and until now there is no problem with the first 'rept' instruction. So maybe you're right and there is no real bug in the new version of the display. But it is a different behaviour in comparision old and new display.


Sorry for reporting an unreal bug. Many thanks for your help.


for the record, what was your delay value?  ~400ms

For the ones with the old pcb layout it was 200ms, for the newer one it is better to use about 500ms to get a reliable solution.

What I wonder for: Why has the 'new display' a longer start-up time than the old ones. The TFT file is always the same.

On your older display pcb layout

 - I measured ~380ms from rest to 0x88 0xFF 0xFF 0xFF Ready

 - I found ~400ms to be reliable with v0.47 of the Editor

v0.47 introduced more language support and changes to upper mem.


While I haven't been able to measure the newer pcb yet

    sending data before ready will be a data loss result.

wrapping you MCU commands rest and 0x88 in millis() to find the timing

    st = millis();  rest  recv 0x88 0xFF 0xFF 0xFF  et = millis()    lapse = et-st;

    and outputting this difference to a monitor to measure = good debugging.


I am more convinced the change in behaviour is firmware version related, every firmware sends 00 00 00 FF FF FF preamble and 88 FF FF FF Ready on power up. When using the rest command and actively monitoring for Nextion Ready before send, would maybe have been a slightly longer startup across versions/pcbs changes - but no change in code and first command should always recognize.


It is probably very safe to say: more firmware changes in future.

Login or Signup to post a comment