Hi folks - just finished several months of designing and fabricating a PCB using a NodeMCU - the board exposes a WiFi interface and exposes 8 ports that I can hook fireworks to and fire each port. Schematic and board layout attached. I am happy to provide the NodeMCU code I have and sample triggers I wrote if it's helpful.
Everything is working as expected and I'm really quite happy.
Couple of questions though:
Per the schematic, I'm using 4 of the onboard NodeMCU pins as output for firing triggers (D5 through D8). When I power on the board, the four fire indicator LEDs for the ports controlled by those pins briefly flash. I assume that's startup behavior of the NodeMCU? A) Is there any way to suppress this? B) If not, I think it's not an issue because the design is that a human using it should never have the arming switch on during power up. And I also have a remote arm override circuit, that, on startup, should always be off. The trigger for the remote arming MOSFET (Q_ARM1) is powered from an I2C expander (MCP23017), so am I right in assuming that the MCP23017 will never maintain state, and because it's powered over I2C, the pinout (GPB6 in my case) will never be powered on startup, and thus Q_ARM1 will always be in OPEN state on startup, mitigating any nodeMCU output pin risk?
As I was developing my software, I had a bug which caused me to essentially send 10,000 unexpected web requests to the NodeMCU. I have code to return 400 in those cases, but in several times while I was debugging it appeared I was able to hang the NodeMCU. It just sat in a weird state, unresponsive, with one or two firing pins looking on. What was worse (and unexplainable) was that I unplugged the whole board, waited 3 or 4 minutes, and then plugged it back in and powered on and I was still in that state. That blew my mind. The only capacitors I have on the board are C1, C2, and C3 (0.1uF or 10uF). Could the NodeMCU have maintained an electrical charge somehow? I tried pressing the RST button but that didn't fix it. If it happens again, is there anything I can do to try to force a reset across the board?
Please note - in the attached board layout I have a copper ground fill that I've hidden to make the rest of the pdf readable.
The MCP23017 can not be powered over I2C, that are communication lines. It has to be powered from the 3.3V line of the NodeMCU - or from the 5V line, but hen you have to add level shifters to the I2C lines.
The MCP23017 when powered up sets its pins to INPUT, after that only changes state when told to do so (over I2C). Resetting the NodeMCU without resetting (or power cycling) the MCP23017s will leave them in the state they were before the reset of the NodeMCU.
Each MCP23017 needs a 0.1µF cap placed close to the Vcc/GND pins. I don't see that in the schematic, that's a likely source of problems.
No idea what you did to "hang" the board, apparently you have been able to upload software after this happened, so it was most likely just a software error. Check the Serial monitor for messages in that case.
Resetting the NodeMCU without resetting (or power cycling) the MCP23017s will leave them in the state they were before the reset of the NodeMCU.
This makes sense, although in my case I unplugged the board so the whole thing should've power cycled, right? Secondarily, how do I reset the MCP23017s without unplugging? Just provide input current to the reset pin?
Each MCP23017 needs a 0.1µF cap placed close to the Vcc/GND pins. I don't see that in the schematic, that's a likely source of problems.
I didn't see anything about that in the datasheet. Do you have a link and/or can you describe more why these are needed and potential affects without them? (PCBs are already made so I'd hate to remake)
Looks unnecessarily convoluted to me. I would find it difficult to spot a reason for spurious activation of the output FETs but if it relates only to the NodeMCU then it is presumably a problem with your as-yet undocumented code. Splitting the "trigger" sources over three different devices looks like a really bad design point to start with.
If you unplugged all power to the board, then the MCP23017s would have reset. It would be the NodeMCU that was retaining the state, presumably due to saving some status in its Flash. How did you start it working again?
If you have omitted the required bypass capacitors, then just solder them under the PCB directly across the power and ground of each IC. In the case of the MCP23017s, they appear to be adjacent pins and you can use a SMD chip capacitor. Mike has a Web page on bypassing but I can't recall the link offhand.
If you unplugged all power to the board, then the MCP23017s would have reset. It would be the NodeMCU that was retaining the state, presumably due to saving some status in its Flash. How did you start it working again?
Honestly I'm not not sure. Fiddled a while and didn't do anything I could discern as predictable.
as-yet undocumented code
Very happy to provide more if it'll help with insight. Please see attached.
Splitting the "trigger" sources over three different devices looks like a really bad design point to start with.
I thought it was a reasonable way to do it since I thought I had to split some amount of I/O to begin with :(. I'm not an EE and am teaching myself by what I can find on the internet. Tried to balance as best I could but always open to feedback for future iterations.
If you have omitted the required bypass capacitors, then just solder them under the PCB directly across the power and ground of each IC. In the case of the MCP23017s, they appear to be adjacent pins and you can use a SMD chip capacitor. Mike has a Web page on bypassing but I can't recall the link offhand.
Got it! Great idea - still would love more info describing why the bypass capacitors are required and where that is in the datasheet so I can learn how to better read these. This is the datasheet for the part I bought from digikey. http://ww1.microchip.com/downloads/en/DeviceDoc/20001952C.pdf
larrywal32:
Great idea - still would love more info describing why the bypass capacitors are required
As a rule of thumb all digital ICs need bypassing, close to the chip. If they don't need it, it won't hurt either, so just make it a habit of adding them. Chips with multiple power pins need a cap at each Vcc pin (like the larger ATmega chips, for example, they have 2-3 Vcc pins, so 2-3 100 nF capacitors) .
That datasheet indeed doesn't mention it, there's not even a reference circuit or typical application circuit given. That's where you will commonly see that decoupling capacitor, and things like the I2C and reset/enable pull-up resistors.
It's way too complex for a simple message board; and I also don't know the full ins and outs, but the key to the matter is that the current draw of these ICs can vary drastically. You're of course talking just mA of current, but the slew rates of these currents can be many A/ms as it goes so fast. At those rates the stray inductance of PCB traces and, worse, vias becomes a serious issue: for a fraction of a ms the voltage at the IC pin can drop drastically as the current in the trace can't ramp up fast enough.
That's where the cap kicks in keeping the supply voltage stable, and that's also why it has to be ceramic type and mounted as close to the power pins as possible.
A commonly used value is 100 nF. It's a bit arbitrary, and not exactly critical. In many cases smaller values such as 47 or even 22 nF have proven to do just fine, but why bother trying: the physical size of the caps is the same, cost is basicially the same (you're not buying them by the million), and 100 nF is simply known to do the job.