Working with the SNAP Module¶
The SNAPconnect E20 contains a Synapse Wireless SM220 surface-mount SNAP module, which it can access
via serial ports /dev/snap0
and /dev/snap1
connected to UART0
and UART1
on the module, respectively.
By default, SNAP-powered modules communicate serially over UART1
, so when making your SNAPstack or SNAPtoolbelt
connection to the module, you should use /dev/snap1
unless you have modified your modules’s default UART settings.
For detailed instructions on SNAPstack, please consult the SNAPstack Users Guide.
In addition to the serial connections, there are two GPIO pins from the gateway that are tied to lines on the SM220 for controlling and signaling.
E20 Pin |
SM220 Pin |
Purpose |
---|---|---|
GPIO 33 |
GPIO_F1 |
You can use this pin as a signaling semaphore or to wake the SM220 when it is sleeping. |
GPIO 34 |
RESET |
You can use this pin to reboot the SM220. |
By default, the SNAPconnect E20 ships with SNAPtoolbelt installed. SNAPtoolbelt can be very handy when needing to perform simple operations or maintenance on the SNAP module.
Waking the SNAP Module¶
At times it may be helpful to have the SNAP module in your E20 sleep, and then be woken by the E20’s processor.
You can easily do this by defining GPIO_F1
on the SNAP module as a wake pin, like this SNAPpy script:
from synapse.pinWakeup import *
from synapse.platforms import *
@setHook(HOOK_STARTUP)
def onStartup():
setPinDir(GPIO_F1, False)
setPinPullup(GPIO_F1, True)
wakeupOn(GPIO_F1, True, True)
To wake the SNAP module you will need to pull the E20s GPIO 33
high, pause a second, and then pull the line low.
Resetting the SNAP Module¶
Just as you can wake a sleeping SM220, there is a pin you can use to reset your module should you need to.
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
Recovering the SNAP Module¶
Several things can make a module unresponsive, including: setting an encryption key that you then forget, or a script that sends the node to sleep with an invalid wake pin defined, or even a script that sends the node into an infinite loop.
SNAPtoolbelt provides help here, with the snap recover
options.
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. So, the first thing to try in module recovery is forcibly removing the SNAPpy script from your SNAP module:
snap recover erase-script SM220UF1
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:
snap recover default-nvparam SM220UF1
This clears the encryption settings (no key, no encryption), sets UART connections to their default settings (UART1, 38,400 baud, 8N1), and clears other settings to their default levels. (Refer to the SNAP Reference Guide for other defaults.)
Typically it is best to start with clearing the script in your node before resetting its parameters, because it is possible for the script to reset (away from default values) parameters that you just reset (to default values).
Note
Resetting your SNAP module to default settings does not automatically mean that other devices can talk
to it, over the air or serially.
It does mean that you now know how to configure those devices to talk to it.
If you have another radio device on channel 13
using network ID 0xABCD
,
you will have to set that device to channel 4
, network ID 0x1C2C
to talk to your defaulted SNAP module.
You can then use that radio connection to move the gateway’s SNAP module to your preferred network settings.
Or, you could change those settings serially from your SNAPconnect E20 — if your gateway is set to communicate serially
the way that your SNAP module is (considering encryption keys and types, serial rates, etc.).
The point is: defaulting a device doesn’t mean you have it where you want it, only that you now know
where to go look for it.
Controlling the E20 from the SNAP Module¶
Just as there are lines from the E20’s i.MX6 processor to the SM220 Series as a wake pin and a reset, there are corresponding pins back to the i.MX6 from the SM220 Series:
SM220 Pin |
E20 Pin |
Purpose |
---|---|---|
GPIO_F2 |
GPIO 32 |
You can use this as a one-bit signal from the SM220 even when SNAPconnect software is not running on the E20. |
GPIO_C4 |
RESET |
This pin is tied to the system reset line on the E20, active low. You can use this to reboot the i.MX6 processor without interrupting service on the SM220 Series. |
The reset line will force a reboot of the E20’s i.MX6 processor. This may cause the loss of unsaved data, and as with any uncontrolled shutdown of a computer it is not recommended that you use this often. It is intended only to recover an unresponsive E20. The following sample SNAPpy script demonstrates rebooting the i.MX6 processor from the SM220:
from synapse.platforms import *
@setHook(HOOK_STARTUP)
def on_startup():
setPinPullup(GPIO_C4, True)
writePin(GPIO_C4, True)
setPinDir(GPIO_C4, True)
def resetE20():
pulsePin(GPIO_C4, 1, False)
In contrast, the GPIO_F2 pad on the SM220 Series can signal the GPIO 32 line on the i.MX6 without any danger to either system, and the signal can be processed or ignored by your E20 program as you choose. The following sample Bash script demonstrates how to watch for the pin change from your gateway’s perspective:
if [[ ! -d /sys/class/gpio/gpio32/ ]] ; then
echo 32 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio32/direction
fi
while [[ `cat /sys/class/gpio/gpio32/value` != 0 ]] ; do
sleep 1
done
echo "Got interrupt!"