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:
Power the Nextion via the USB port
display backlight remains off
all of the GPIO’s assert themselves for somewhat less than one second (there are state LED’s on the GPIO board)
GPIO then goes out
display backlight then comes on
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?
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.
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…”
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.
This forum is in no way affiliated with NEXTION®, ITEAD STUDIO®, TJC®, or anyone else really. All product names, logos, and brands are property of their respective owners. All company, product, and service names used in this website are for identification purposes only. Use of these names, logos, and brands does not imply endorsement from the respective rights holder(s).