GPIO briefly asserted when display powers up

1

Environment:
NX4827P043_11, usb powered via serial dongle,
GPIO board from Cheapcontrols.com, (same behavior, internal or external power)
Latest version of Nextion Editor installed to Win 10 Pro.
I can make a video available clearly showing the behavior should my description not be clear,

Using instructions provided at CheapControls I’ve managed to make the GPIO connected relays perform as described in the tutorial.

Reproducing the problem:

  1. Power the Nextion via the USB port
  2. display backlight remains off
  3. all of the GPIO’s assert themselves for somewhat less than one second (there are state LED’s on the GPIO board)
  4. GPIO then goes out
  5. display backlight then comes on
  6. Program loaded to unit then behaves normally / as expected.

Clearly I can’t have GPIO’s all asserting themselves when the HMI powers up. I’ve looked around trying to understand the GPIO functionality more deeply but I’m not really getting anyplace.

Is this observed behavior an artifact of how the HMI powers up or am I failing to do some sort of pre-initialization with the GPIO’s that cause them to remain off until actually commanded?

I’m using the HMI to control several relays attached to downstream systems and you can imagine the chaos that would ensue when cycling power to the HMI!

I’m hoping that there is a programmatic way to address this otherwise I’ll need to come up with a power-on sequencing circuit that inhibits the relay drive power until the HMI comes up.

Looking at the back of the board I see a number of open pads. Assuming I need to go the hardware route is anybody aware of a signal available on one of these pads that would signal that the HMI has fully initialized and the stored program is running?

Thanks,
Chris

2

Just a quick update, Nextion rached out to me asking for a video of the behavior I described in this post. I sent it to them this weekend but haven’t heard from them. I also received an email from a person affiliated with them and they confirmed the behavior as well.

Seems I may have found a bug. Gratifying to have them reach out and ask for more details.

-Chris

3

Here is the resolution from Nextion. In essence it states that when the HMI powers up the GPIO’s are expected to be in an indeterminate state and that any external circuitry that depends on the GPIO functionality provided by the Nextion device must account for this. It is puzzling to me that the older “enhanced” device doesn’t exhibit this behavior but there you are.

During power up,
- you have an indeterminant state during boot
- you enter a weak pull-up phase as stated in pioX until your HMI takes over
- you have your chosen GPIO configuration by cfgpio asserted.

The power on fail-safes and state persistence is to be handled by user’s circuit.

I find it interesting that my experience using and programming microcontroller based systems (Teensy’s, Arduino’s, Beagleboards, ESP’s and many others) I have never run into this behavior.

The preson from Nextion that responded to my support request characterized my application as “mission critical” (I intended to use the GPIO functionality to command some relays in use in my ham shack) and that I would need to ensure my circuitry accounted for this (undocumented) behavior.

Further, the gentleman made it quite clear that they have absolutley no intention of addressing this behavior. Quite disappointing.

So my options are to use a different HMI (perhaps the Enhanced, but I have a nasty taste in my mouth) or re-design the GPIO drive circuitry to incorporate a time delay in the GPIO power distribution rail. What would be so much better is if Nextion exposed a pin someplace that could be used to indicate that the HMI was running the user program.

All of which are extraordinarily unlikely to happen.

I should add that Nextion has updated thier documentation section 6.19 (GPIO) detailing the precise values of pullup expected making mention that “As with any MCU there is a short period of uncertain level on Power On…”

4

This is definitely not typical GPIO behavior on modern microcontrollers and it’s something Nextion should absolutely address with a simple firmware update. This isn’t the Basic or Enhanced series where they’re constrained by the amount of remaining flash memory making it nearly impossible to roll bug fixes or new features into the display firmware. This is the Intelligent series with substantially more memory and Nextion continues to roll out updates and firmware changes to these displays practically monthly. Nextion’s own ‘cfgpio’ documentation clearly shows that the GPIO can be configured as inputs or open drain. The same documentation on ‘pioX’ say the “Default mode when power on” sets the GPIO pins to inputs with pull-up. Even “weakly” pulling up the GPIO’s puts these pins at 3.3V which isn’t much different than defaulting them to HIGH outputs in many cases. The GPIO shouldn’t be actively pulling a line up OR down unless expressly programmed and configured to do so. Nextion should simply change the default GPIO power on configuration to tri-state, hi-z, floating, etc so the display isn’t inadvertently driving GPIO lines and keep them in this state until a ‘cfgpio’ tells it otherwise. It’s such an easy fix to an obvious problem but instead of simply addressing the issue by changing 1 LINE OF CODE in the next Editor release, they actually had the audacity to tell developers they need to design their own hardware specifically to take into account the uniquely bizarre GPIO behavior found in a certain subset of models within Nextion’s larger line of of HMI displays.

“…is to be handled by user’s circuit.” Very disappointed to see this kind of response and total lack of product support.

In light of Nextion’s response, the simplest solution in the situation of the original poster might be to just switch to an Enhanced display model if the lesser features and smaller screen sizes would work for you.

Another quick thought, Nextion’s literature on ‘cfgpio’ states that the pull-ups of the Intelligent models have a typical resistance of ~66k. Maybe add another similarly sized resistor to ground on each of the Nextion’s GPIO pins basically forming a voltage divider so the pins essentially “float” when they default to input w/ pull-up at startup. The Nextion’s GPIO push/pull outputs are rated at 1ma so you shouldn’t have much problem pulling the pins LOW and/or HIGH even with the pull-down resistor added. Just an idea.

5

Ratnin,

I share your frustration at this response, however despite not liking (or wholly agreeing with) the response I must respect that thier stance is clear. It won’t be addressed. Thier assertion regarding the indeterminate state of GPIO’s for any any microcontroller or microcontroller based system on startup isn’t “wrong”. That is in fact the norm and as you point out, can and should be addressed in the power on initialization sequence.

I would hasten to add that as this appears (at least to me) to be related to the HMI system formware, presumably executed at startup, I find it highly unlikely that changing code in the Nextion editor will have any positive impact on the observed behaviour. Recall that the output of the editor is in itself a program that is loaded by the system post startup initialization.

I am curious. In your response you point out that Nextion has what appears to be a regular firmware release schedule. I am unaware of this firmware location and the steps required for blowing it into the HMI. Perhaps you can share that information? Please feel free to DM me or email to dvbasi@hotmail.com.

Like you, I am disappointed by the response. I now have an ‘Intelligent’ series module that I can’t use for my intended application without jumping through some admittedly minor hoops related to external circuit design. Holding off the supply rail for some period of time is a viable fix but one I’d rather not have to go through. I did suggest to the person at Nextion that responded to my support request that they explicitly document this behavior. That person stated they were to fix thier documentation by being more explicit about the electrical characteristics of the pins (a good step forward). Simply describing, however accurately and detailed it may be, the electrical characteeristics of the GPIO on startup doesn’t really “tell the story” to those in the audience that aren’t electronics engineers disciplined in the nuance of circuit behavior in microcontrollers or systems based on them. It would have been a further step forward to, perhaps, use my situation as an opportunity to ‘educate’ non-professional users regarding this specific circumstance.

That appears unlikely.

As you point out (as I may have), dropping back to the Enhanced display is a viable solution. I don’t need the more advanced capabilities that the ‘Intelligent’ series provides but I do need all eight of the GPIO’s.

I’m still internally debating how much effort I want to go through for what was going to be a short project and accompanying article for QST. If I decide to move forward I’ll be quite specific about what I encountered and shall do so in a fair and as far as is possible, objective way.

I’ll close with this:

I found the Nextion HMI to be an ideal component for my use case. It appeared to tick many boxes that neatly address issues faced by electronics hobbyists. Digging in revealed what I considered to be a significant issue. Getting the attention of Nextion support was not a simple task and the resulting response was less than satisfying. Conside that they have never (at least to my knowledge) held thier product out as something an hobbyist would find suitable for use. Indeed, if you look at thier support site they are quite specific (perhaps adamant) that “Reading of the documents/forum topics for Nextion understanding is a must. Not understanding Nextion does not make a Level 2 Hardware issue.”

Thier assertion, quite simply put, is that this behavior is not abnormal and thus is not a “Level 2 Harware issue”.

Imagine how ‘bent’ I’d be if I spent several thousand dollars on a number of Intelligent HMI’s for a ‘real product’, discovered what I found to be a “Level 2 Hardware” issue, reported it to the vendor then was informed that this was in fact ‘normal’ behavior. My boss would probably look at me sideways and wonder if he hired the wrong person.

So, do I:
1 - Retain the Intelligent HMI module and redesign the external GPIO circuitry
2 - Swap the Intelligent for an Enhanced HMI module
3 - Completely re-factor the project to use a different approach
4 - Chuck it all and put a bunch of toggle switches and LED’s in place to control the station gear and call it a day

No matter what, the marketplace is full of interesting parts and companies that are interested in actively supporting ‘hobby grade’ users like me.

Thanks for reading this far. Good luck to the rest of you using the Nextion components. They appear to be good, useful devices with a number of appealing features. In my opinion thier support isn’t one of those features.

I’ll not get into any back and forth with Nextion. I reported the issue, they responded, end of story.

-Chris

6

My solution would be to use a 74HC244 buffer and simple capacitor/resistor on the enable.
This gives the delay and buffers & protects the GPIO of the nextion.
As my next project with the display was multiple rs232 inputs its good to know of the behavior.

1 Like
7

paulvk,

Excellent idea. Elegant, straightforward and simple to implement.

-Chris