Hi all, I’m re-experiencing this issue… abt 5 mo ago I realized I was powering the boron of my i2c pull ups and latching it. I fixed this with a iso1540 itolator on the i2c lines… That seems to have worked up untill last week, we’ve made some changes to the circuit and seem to be experiencing the same bug…
anyways… right now I’m trying trying this airwire that ties my EN and RST pins together… we’ll see how that goes… Anyways the real ROOT of this problem is that EN is not the actual mcu’s EN, but the regulators… so the mcu can get powered off other stuff…
@rickkas7, I’m looking forward to you’re app note on the subject… One other think on the documentation side… The en pin should really be labeled 3.3V_EN correct? When I first layed out my boards I assumed that the en pin was tied to an en mcu pin which would pause the mcu… I should have know better I guess. I don’t mean to whine about this but it would seem that others have made that same assumption. While you’re on the subject, it would be great to edit the boron datasheet pin function section to include something about this…
@peekay123 and @rickkas7, do either of you know if the rst pin works as I would expect it to? I would expect it to stop the mcu while low and re-start the program even if power is applied to other pins… it seems a little silly to have to worry about sizing series resistors everywhere or adding in isolators every time I connect a pin. In nordic’s datasheet it says pin 0.18 is a ‘configurable RESET’, I guess I’m wondering how it’s configured?
The RESET pin is considered configurable only because it can be moved to different pins using the PSELRESET registers. Once configured, it should always work to reset the MCU.
@rickkas7 Not to rush the team, but just an indicator that that application note on watchdog/resetting cannot come fast enough. I am making decisions and PCB redesigns in the next week (some already submitted). I am adopting the competitor to some extent but am still planning to retain a Boron front to an extent which depends on whether my confusion on the EN reset rules can be resolved in the next week. I love the Boron form factor, cloud programming, and Particle console, but it is hard to justify $.40/mb when the competitors can give me one fourth of that.
Knowing that the Boron can be used with 99% reliability (if it can be power cycled programmatically without causing brownout/never resets) will go a long way to persuading me to continue paying extra for Particle.
If I could choose any company to have the best cellular IoT product, I would probably choose Particle, because I love the company and the user interface and everything.
But I just cannot justify sticking around at 40 cents/megabyte LTE and non-stably-resettable hardware when the competitor offers me stable hardware at 10 cents/megabyte LTE.
If Particle can sell me 10 cent/mb LTE and a stably-electronically-resettable Boron board, I can’t see why I won’t be a committed customer for life as I grow my fleet.
If Particle can offer me a stably-electronically-resettable Boron board at the advent of this application note, but still require the steep 40 cents/mb LTE, then I will be able to stick with Particle to a lesser/supplementary extent while adopting a hybrid solution with competitor.
I hope this feedback is helpful, and I look forward to the application note.
And I thank you again for your attentiveness and response.
Ok all- I’ve been testing my dutying of a boron on 2 devices using the en pin tied to the rst pin for abt a week now and it hasn’t bugged… I guess what im wondering is if I were to only use the rst pin, what would the modem do??? would It remain powered and waste power??? there seems to be a not gate for the rst on the modem… which seems wierd, I’m not really sure how that behaves… I think it’s best to rst+en…
@Paul_M what I would do is tie the rst pin and the en pin both to seperate gpio of you’re ‘master mcu’ or whatever you use to power cycle the boron… this gives you plenty of options…
The reset pin is only connected to the MCU reset line. This is done intentionally.
On Gen 2 devices (Electron/E Series), you can use the RESET button or System.reset() and when the device reboots, the cellular modem will still be connected if it was connected before the reboot. This greatly speeds up the time to resume activity after a firmware flash or reset.
On Gen 3 devices, that was the intention but prior to 2.0.0-rc.2, the modem was reset during Cellular.on() after the reboot, eliminating the benefit. In 2.0.0-rc.2 and later, this is fixed so the cellular connection should stay up through a firmware flash OTA, so you can avoid most of the blinking green phase.
The EN line depowers both the cellular modem and MCU on the Boron. As long as you have no leakage current into GPIO or 3V3 when EN is pulled low, it will reset both the cellular modem and MCU.
MCU reset occurs on the falling edge of RST, but since EN affects the power, you must keep it low long enough for everything to power down. At least a few seconds, preferably 30 seconds.
rickas- I’m still a bit confused on that last sentence… rst occorrs only once?? shouldn’t rst keep the mcu in the reset state? w the clock’s stopped and stuff? Is there supposed to be some sort of order of operation to this??
Is there a timeline for 2.0.0-rc.2?
Is the cellular reconnection disparity I measured between 1.3.1-rc1 and 2.0.0-rc1 addressed in 2.0.0-rc2?
Regarding EN reset, is my following understanding correct:
I have another MCU (measures sensors) connected to Boron over UART.
I can power these either with 5V / Boron VUSB, or with 3.3V Boron output.
I cannot use the other MCU to watchdog the Boron’s EN if powered by the global 5V because there might be leakage current into UART RX which prevents reset;
I also cannot use the other MCU to watchdog the Boron’s EN even if powered by the Boron’s 3V3, because EN disables the 3V3, so the other MCU would be committing suicide and wouldn’t be able to restore EN high after committing suicide.
It is therefore necessary to use a completely different external MCU to watchdog the Boron’s EN pin, which is A) not connected to any other pin on the Boron, and, B) which is continuously separately powered.
Such a device is logically impossible to exist, because in order to watchdog the Boron’s EN pin, it has to be connected to the Boron in some fashion beyond the EN pin in order to determine whether the watchdog condition is met.
Therefore it is impossible to have a stable external hardware watchdog for the Particle Boron without using some sort of sophisticated optical isolation hardware. Only a device which power cycles the Boron with EN at fixed intervals, being ignorant of whether the Boron needs a reset, is possible.
We control the EN pin from an external chip (AB1805) that’s connected by I2C. That’s easier because the I2C pull-ups go to 3V3 and I2C is open-collector so there’s no current leakage.
For serial, since it’s push-pull you could run into leakage. If you have the ability to turn off the port, that’s a good option. On some microcontrollers you can turn the serial port off and turn the TX pin into high-z, input mode, or low to avoid current leakage.
If there is no way to deactivate the serial in software, then a hardware buffer with a high-impedance mode will probably be necessary.
Basically, you just need a way to make any external devices with a push-pull driver connected to an nRF52 GPIO go low or high-z before going through the EN low depowering cycle.
What would be the recommended approach to power the AB1805 if we need to hold EN for ~30 seconds when 3V3 is off? Using a capacitor? My use case uses LiPo and Solar Charging.
I don’t think this is impossible as you said above ^ in fact, I’m pretty sure it isn’t since I have a bunch of fielded devices that I’m constantly power cycling…
if you want a reliable watchdog I think what you’d do is the following:
OUTPUT from boron that ticks every couple seconds when it’s running normally…
attiny85 with an INPUT connected to the boron blinker… also connected w gpio’s to rst and en. if this doesn’t see the blinker go high for a while… it does a restart by doing the following:
pull rst low;
wait 1 sec;
pull en low;
wait 30 sec;
pull en high;
wait 1 sec;
pull rst high;
the input to the attiny should be high impedence and shouldn’t power the boron, if you’re paranoid though, you can gnd that during the 30s as well… so there’s no potential across boron.
the attiny should be powered from it’s own regulator from the VLI pin on the boron- which never shuts off
Great to have platform recommended watchdog options
The advanced option complexity, makes me explore ways to achieve close to the same degree of reboot effectiveness with the simple option (for products in the field after development, where resets should be rare).
...
if (System.resetReason() == RESET_REASON_PIN_RESET) {
Particle.function(String(random(10, 1000)), ""); // <--- Added
Log.info("RESET_REASON_PIN_RESET: either RESET or hardware watchdog");
}
...
As noted in 5.14.4, the modem is kept alive and even connected, during a reset in 2.0.0. So for an extensive reboot, I would also need to power cycle the modem in the example above.
Having power cycled the modem and re-initialized the session data, what other predominant type of reboot requiring issues make the 30s deep power-off more effective?
