TLDR: A long trace to the EN pin may pick up enough noise from the cellular radio to continuously reset a Boron.
I had an issue where most of my Boron devices would not connect reliably. They typically were in a state where they flashed green as if they were trying to establish a connection and then would reset (LED goes off, white, then flashes green again). This issue happened most often when my Boron was plugged into the Adafruit Terminal Block Breakout Feather Wing.
Thanks to @ParticleD, the particle engineering team theorized that the switch on that FeatherWing was picking up noise from the antenna, specifically while sending / receiving data. This noise was causing the EN pin to go low enough to reset the power switch (U2) and consequently reset the Boron.
You can see that the EN pin on the power switch is pulled up by a 100K resistor. Apparently this is not strong enough to overcome some noise on a long trace to the EN pin as is the case on the FeatherWing. Particle recommended using a smaller pull-up resistor (10K) to keep the EN pin high in the presence of noise.
Below are some screenshots of my scope connected to the EN line. All of these tests were done with the Boron in the FeatherWing. The first test was with no additional pull-up resistor and the Boron was in a continuous reset cycle.
In almost all cases, the drop to around 1.7V on the EN line was enough to reset the device.
Next I used a 22K resistor from EN to BATT (I was powering with battery only).
The drop to around 2.5V during cellular communication was not always enough to reset the device however there were cases where enough noise was picked up that the device would reset.
Finally I tested a 10K pull-up as Particle suggested.
There is still a measurable drop (600mV) but the EN line is effectively kept high and the device works reliably. I suspect that if the battery were extremely low, it may be possible to experience reset events but I have not yet tested this.
I appoligize if this is a stupid question, but I’m learning here.
Since the EN pin is normally at 3.8V, is there any concern leaving it connected it to the Battery voltage of ~4.1V through a 10K resistor ?
I’m trying to figure out the safest way to Pull the EN pin Low with a GPIO, without wasting precious battery power 24/7. The 3.8V on the EN pin has me concerned about the Voltage Potential.
But from the looks of this post, maybe I shouldn’t be ?
You can actually go lower than 10K. I considered suggesting 4.7K to give a better margin.
I believe the reason for the really weak 100K pull-up on EN on the device is for the use-case of using the EN pin pulled low to put the device in a very, very low power state to preserve battery. A strong pull-up will increase the current when you’re trying to put the device in a low-current mode by grounding EN.
The reason the power switch on the Adafruit terminal block FeatherWing picks up so much RF interference is that when in the on position, the line is left floating and the switch is right under the antenna connector.
I’m testing all of my Boron devices and finding that even a 10K pull-up may not overcome the noise issue. I can see that the noise is a fairly high frequency so I’ve decided to use a filter capacitor instead. I put a 200nF capacitor (just a value I had handy) between EN and GND and see no measurable noise on the EN line any longer. This also addresses @Rftop’s question of additional leakage current when powered down. The only leakage in a powered down state is through the on-board 100K resistor and will be in the 10’s of micro amps range. I also had a 1uF capacitor handy and that had the same effect. The larger capacitor just causes a very tiny delay in power on/off.
I’m seeing this issue with a boron I have on a remote site. It’s fitted in the middle of an Adafruit tripler board along with 2 Adafruit feather mini non-latching relays stacked on each other, and an xbee taking up the spaces each side. I am seeing constant pin resets, like every minute or 2 minutes. I have nothing connected to the reset pin, and I’ve tried putting an 1uF cap between EN and GND. At first I though this had worked when we reinstalled it on Friday because it wasn’t pin resetting, until my tech left site and then of course it started doing it and hasn’t stopped since.
It’s very frustrating and I need to get to the bottom of it because this is one of many issues I’ve had with this particular site and this is one that I believe just shouldn’t happen.
I should’ve mentioned, due to nuisance triggers that I’m also trying to resolve (the Boron waits for input from an xbee to then fire the relays and send a Particle.Publish), I’ve stopped the relay and Particle.Publish code for now until I can sort out both these issues. The setup is powered by a 12V to 5V USB converter.
// This #include statement was automatically added by the Particle IDE.
#include <RFM69-Particle.h>
#include "Particle.h"
// Set the pin you've connected your non-latching relay to here:
const uint16_t RELAYRED_PIN = 8;
const uint16_t RELAYGREEN_PIN = 5;
// The blue LED next to the USB connector will be turned on when the relay is turned on
const uint16_t LED_PIN = 7;
//set input to initiate light sequence
const uint16_t INPUT_BUTTON = 6;
bool relayRedState = false;
bool relayGreenState = false;
bool override = false;
void setRelayRed(bool state);
int relayHandler(String param);
void buttonHandler(system_event_t event, int param);
unsigned long redOn = 0;
unsigned long greenOn = 0;
unsigned long now;
byte inChar[80];
void setup() {
Serial.begin(9600);
Serial1.begin(9600);
pinMode(LED_PIN, OUTPUT);
pinMode(RELAYRED_PIN, OUTPUT);
pinMode(RELAYGREEN_PIN, OUTPUT);
pinMode(INPUT_BUTTON, INPUT_PULLUP);
setRelayRed(false);
setRelayGreen(false);
Particle.function("relay", relayHandler);
Particle.function("override", overrideHandler);
Particle.function("buttonPress", buttonPressHandler);
Particle.variable("Override",override);
System.on(button_click, buttonHandler);
inChar[0]=0;
inChar[1]=0;
}
void loop() {
now = millis();
if ((now - greenOn) >= 60000 && (relayGreenState) && (!override)) {
setRelayGreen(false);
setRelayRed(true);
}
else
if ((now - redOn) >= 10000 && (relayRedState) && (!override)){
setRelayRed(false);
}
// read the input value
inChar[0]=0;
inChar[1]=0;
if (!relayGreenState && !relayRedState){
while(Serial1.available()){
for (int i = 0; i < 2; i++){
inChar[i] = Serial1.read();
delay(10);
}
}
if (inChar[0] != 0){
Serial.print("inChar is ");Serial.print(inChar[0]);Serial.println(inChar[1]);
}
if (inChar[1] == 10){
if (inChar[0] == 42){
Particle.publish("xxxxx","buttonPress", PRIVATE);
if (!override){
// Particle.publish("xxxxx","timer", PRIVATE);
// setRelayGreen(true);
}
}
}
}
while(Serial1.read() >= 0);
}
void setRelayRed(bool state) {
digitalWrite(LED_PIN, state);
digitalWrite(RELAYRED_PIN, state);
relayRedState = state;
redOn = now;
}
void setRelayGreen(bool state) {
digitalWrite(LED_PIN, state);
digitalWrite(RELAYGREEN_PIN, state);
relayGreenState = state;
greenOn = now;
}
int relayHandler(String param) {
if (param.equals("on")) {
setRelayGreen(true);
Particle.publish("xxxxx",param, PRIVATE);
redOn = millis();
override = true;
return 1;
}
else
if (param.equals("off")) {
setRelayGreen(false);
setRelayRed(false);
Particle.publish("xxxxx",param, PRIVATE);
override = false;
return 0;
}
else {
return -1;
}
}
int overrideHandler(String param) {
if (param.equals("true")) {
override = true;
return 1;
}
else
if (param.equals("false")) {
override = false;
return 0;
}
else {
return -1;
}
}
int buttonPressHandler(String param) {
if (param.equals("true")) {
Particle.publish("xxxxx","timer", PRIVATE);
return 1;
}
else {
return -1;
}
}
void buttonHandler(system_event_t event, int param) {
setRelayRed(!relayRedState);
override = !override;
}
Your code seems to be looking for Serial1 input 0x2A 0x10 (*\n) and are not interested in anything else and your Serial.print() statements are merely for debugging, right?
If so, you could use this instead
if (Serial1.find("*\n")) {
Particle.publish("xxxxx", "buttonPress", PRIVATE);
if (!override){
// Particle.publish("xxxxx","timer", PRIVATE);
// setRelayGreen(true);
}
}
else {
// Serial1.find() timed out
}
Otherwise I cannot immediately see anything wrong with your code.
Can you provide any background what typically happens before the green flashing and particularly before a reset happens?
That’s correct, it’s a pretty simple code. The Serial1.find is a handy tip thank you.
Unfortunately I can’t give any extra detail because as far as I’m aware, nothing particular happens before a reset. It just…happens.
I was recently using another Feather board (not a Particle device) and saw a reset issue that was coming from the RST pin. My issue above was only on the EN pin. In both cases I saw an improvement with a filter cap on those lines. Have you checked for noise on both pins?
In my case, the reset was easily reproducible so I was able to tell with a simple test if a filter capacitor helped.
I thought the RST pin was causing issues was on the Adafruit nRF5280 Feather board. My problem was with the board resetting when USB power was disconnected. In that case, it may have been as simple as the 3.3V regulator drooping when it switched from USB to battery power. I believe the RST pin is the same P0.18/Reset pin of the nRF52840 on both boards. The internal pullup is 13k for that pin so it probably isn't susceptible to RF noise. Then EN pin of the Boron on the other hand has a 100k pullup which is weaker against noise.
We are also considering making an adapter board that fits between feather headers in order to add the suggested resistor / cap.
@trpropst, what was your final fix for this? Resistor to VBAT and capacitor to EN-GND? Or just capacitor EN-GND? Has this fix held up in the field?
@rickkas7, why isn’t this issue and other EN related issues in the Boron’s datasheet? There is an empty section for known errata. It seems like this should be on there, as well as leakage to EN pin, 124 day bug, etc.
My last design with the Boron used a 10k pull-up (to Vbat on EN and 3V3 on RST) along with a 10uF filter to GND on each pin. I was more concerned at the time with reliability than power consumption.
I unfortunately stopped work on the Boron platform, primarily due to this other issue and the long time it took to get a resolution through Particle. Particle did eventually replace all my affected devices but not in time to salvage the project.
Have a similar phenomenon on the RESET pin on B523, so likely also with B524, only with actual resets on one unit out of about 15 while running 2G with our own board. The external 3V and 4V supplies are steady as a rock while it happens.
The only thing connected to the reset pin is a close by TPL5010 (RSTn) powered from the same steady 3V supply.
Forcing the module to run 2G, and putting a scope on the reset line during power up, the reset line dips 1.52V from 3.3V for close to 1ms as in the original case above. The internal pull-up is measured to about 10K and seems to be in the nrf52840 (PIO do not disclose correct schematics for this module).
The fix has been to add an external 10K pull-up from RESET to 3.3V, reducing the dip to safe levels.
Then found the SOM evaluation board also has a 10K pull-up on RESET external to the module. It would be a more than helpful addition to the B524 datasheet.
