14
SNAPconnect E12 User Guide — 116-081614-030-B001
Resetting the SNAP Module
There is a pin you can use to reset your module should you need to. (This is necessary, for example, when you reset
factory parameters on the node.)
The E12-snap-utils package also provides a script to assist with this. Invoke this Bash script to briefly pull the reset pin
low and then release it to high, resetting the node:
/usr/local/bin/reset-snap-node
While it is important to be able to do this, in most circumstances it will be less useful day-to-day. (If you need to reset
your SNAP module daily, you may have code issues you need to address.)
Restoring Functionality to an Unresponsive SNAP Module
The risk of having a module that provides several configuration options is it expands the possibility of a
misconfiguration causing you to lose contact with the module. Several things can make a module unresponsive,
from setting an encryption key that you then forget, to putting a script on the device that sends the node to sleep with
an invalid wake pin defined.
The Synapse Wireless Portal software provides mechanisms for node recovery, but since you cannot make a serial
connection from the SNAP module in your E12 to Portal, that functionality needs to exist on the E12 as well.
If you find that your SNAP module is unresponsive or unreachable over the air or serially, the first suspect is typically
the user script on the module. Many a programmer has accidentally specified the wrong wake pin or accidentally
dropped a node into an endless loop. So, the first thing to try in module recovery is forcibly removing the SNAPpy
script from your SNAP module:
sudo flash-bridge -e -p RF220 (for 2.4GHz equipped gateways)
sudo flash-bridge -e -p RF320 (for 915MHz equipped gateways)
WARNING:
Addressing the wrong firmware for your unit may render it inoperable, perhaps even permanently. If
you are unsure of which firmware to address, contact Synapse customer support.
This leaves your SNAP module’s NV parameters untouched, but removes the existing SNAPpy script from the node.
You can then load an appropriate script over the air or serially.
If this does not restore your access to the node, the most likely reason for your inability to communicate is
mismatched configuration (NV) parameters on the node. This could be the result of different encryption keys or
encryption types, misconfigured UARTs, differences in how many CRCs are expected, or some other configuration
setting. The easiest thing to do next is to have the node default its NV parameters, which you can also do with
flash-bridge
:
sudo flash-bridge -nv -p RF220
(for 2.4GHz equipped gateways)
sudo flash-bridge -nv -p RF320
(for 915MHz equipped gateways)
Summary of Contents for SNAPconnect E12
Page 30: ...26 SNAPconnect E12 User Guide 116 081614 030 B001 E12 Dimensions ...
Page 34: ......
Page 35: ......