Elma TIPS for VPX System Integration: What the heck are SYS_CON*, NVMRO, and MaskableReset*?
At Elma, not only do we get tons of pre-sales questions, we also field plenty of questions during design phases, preliminary design reviews, and critical design reviews, not to mention all the post-sales questions for both standard and custom products. So, when the same question keeps coming up, we know it’s something a lot of customers want to hear about.
For nearly 40 years, we’ve been providing industry with high-quality embedded computing products — everything from extrusions and card guides to backplanes, chassis, boards, and integrated systems. Our success comes from our customers, and their questions and feedback, which help us do things better.
The Questions We Keep Getting
In this Elma TIP, we’re going to tackle some very basic starting points for VPX system integration. Customers often ask us what SYS_CON*, NVMRO, and MaskableReset* are for, or we get support calls from folks who can’t get their systems working, and it turns out to be an issue with one or more of these three signals on the backplane.
SYS_CON* - Your System Controller
Here’s the deal: an OpenVPX system needs to have one slot, and only one slot, designated as the system controller.
On Elma backplanes, each slot has a 2-pin header connector with SYS_CON* on one pin and a digital ground on the other. You need to install a jumper on this 2-pin header for one slot to tell the board in that slot “Hey, you’re the system controller.” The system controller drives the bused REF_CLK down the backplane for other boards to use.
If no slot is designated as the system controller, your system likely won’t operate. Seems simple enough, but we’ve been there with customers who spent hours troubleshooting only to find out they forgot this critical step.
NVMRO - Non-Volatile Memory Read Only (AKA Write Protection)
NVMRO is basically like a write-protect signal. Our backplanes include a pull-up resistor to 3.3_AUX, and if you leave it alone, NVMRO stays asserted (write-protected).
Elma backplanes also have a 2-pin header connector with NVMRO on one pin and a digital ground on the other. Install a jumper on these two pins to de-assert NVMRO and allow writes. In some systems, we wire these pins to a switch or chassis I/O, so you can easily control NVMRO remotely.
Here’s a classic support call we get: Someone tries to update firmware on a board and after numerous attempts, they can’t change the firmware. They’re pulling their hair out wondering what’s wrong. Turns out, NVMRO was asserted and wouldn’t let the firmware update. We tell them to install the jumper to de-assert NVMRO, and boom—firmware upgrade works perfectly.
MaskableReset* - The Signal Most People Don’t Use
MaskableReset* is an optional local reset input to a plug-in module, provided in addition to the global SYSRESET*. Honestly, we rarely see customers use the MaskableReset* signal.
However, since many of our backplane designs include a 2-pin header connector at each slot that lets you connect that slot's MaskableReset* signal to a common MaskableReset* signal on the backplane. Then there’s another 2-pin header that has the common MaskableReset* signal on one pin and a digital ground on the other.
Here’s where it gets interesting: we’ve seen cases where people have installed jumpers on these headers for no particular reason, and the result was their plug-in cards were held in reset. The cards just sat there doing nothing. So, here’s some good advice: don’t install these jumpers unless you actually need them.
The Bottom Line
These three signals might seem simple, but getting them wrong can cause major headaches:
• SYS_CON*: Make sure exactly one slot has the jumper installed
• NVMRO: Check that write protection is off before trying firmware updates
• MaskableReset*: Leave the jumpers out unless you specifically need local reset control
When customers call us with mysterious system issues, checking these three signals is often where we start. Get these right, and you’ll save yourself a lot of troubleshooting time.
Need Help?
Got questions about these signals or other VPX integration challenges? Give us a call. We’ve probably seen whatever issue you’re dealing with before, and we’re here to help you get it sorted out.
