I have a sketch I am using with my accelerometer based sensors in the park. All was going well with both counts and stability until I decided to add a “napping” state to the code. The idea was that the device would “nap” during the day between “taps” from the accelerometer. These taps caused D2 to go high which would trigger a hardware interrupt when the device was asleep and would BOTH wake the Electron and trigger an interrupt if the Electron was napping. I differentiate napping from sleeping (which it does at night) as sleeping is DEEP and ends in a reset in the morning.
The full repository for this code is on Github but, as it is over 700 lines long, it is too much to ask for anyone to wade in so I will highlight some items below which I think may be at issue.
First, here is the observed behavior:
The code functions perfectly as long as lowPowerMode is false.
The code functions perfectly for the first hour when put into lowPowerMode - napping and waking as expected.
The device wakes as expected at the top of the hour and sends the data via a webhook, stays awake for 90 seconds (so I can update it if needed) and then starts napping - again just as expected.
After that, the device will wake on tap three times, then it awakes, connects to Particle, sends the 0.8.0rc-4 device health data and becomes unresponsive until the watchdog timer resets it.
So, you don’t have to dig into my code, here are some highlights:
// One line ISR - sensorDetect is defined as volatile
void sensorISR()
{
sensorDetect = true; // sets the sensor flag for the main loop
}
// Here is where I pet the watchdog
void watchdogISR()
{
digitalWrite(donePin, HIGH); // Pet the watchdog
digitalWrite(donePin, LOW);
}
// Here is the napping state code - commenting out the System.sleep() line fixes this issue
case NAPPING_STATE: {
if (connectionMode && verboseMode && state != oldState) publishStateTransition();
if (connectionMode) disconnectFromParticle(); // If connected, we need to disconned and power down the modem
watchdogISR(); // Pet the watchdog
int secondsToHour = (60*(60 - Time.minute())); // Time till the top of the hour
System.sleep(int2Pin, RISING, secondsToHour); // Sensor will wake us with an interrupt
delay(30);
state = IDLE_STATE; // Back to the IDLE_STATE after a nap
} break;
// Here are the functions this state calls
void publishStateTransition(void)
{
char stateTransitionString[40];
snprintf(stateTransitionString, sizeof(stateTransitionString), "From %s to %s", stateNames[oldState],stateNames[state]);
oldState = state;
waitUntil(meterParticlePublish);
Particle.publish("State Transition",stateTransitionString);
Serial.println(stateTransitionString);
lastPublish = millis();
}
bool disconnectFromParticle()
{
Cellular.off(); // Turn off the cellular modem
controlRegister = FRAMread8(CONTROLREGISTER);
connectionMode = false;
controlRegister = (0b11101111 & controlRegister); // Turn off connectionMode
FRAMwrite8(CONTROLREGISTER, controlRegister);
return true;
}
I know this is a lot to ask but any help is appreciated on two fronts:
General guidance and advice on how to track these problems down. Serial.print fails when the device sleeps and it is not connected so I can’t publish - tried using Led flashes but need more insight into what is going on.
Comments, advice, criticism of my code is welcome and appreciated. I know I have a lot to learn.
Although it’s not exactly addressing your symptoms this issue might be related
Since you are also using attachInterrupt() and stop sleep, this might somehow be caused by the same thing.
You could try detaching the interrupts before entering stop mode sleep.
BTW, if you want to wake on the full hour you can also use something like this.
This ensures that the sleep periode is never too short or even negative (which would cause an “indefinet” sleep) and also allows to alter the boundary down to the second).
It is using the tap detection feature to sense a car running over a pneumatic tube across the road. The accelerometer is attached to a small rubber diaphragm that flexes when the car runs over the tube. The rap is detected and the accelerometer raises the interrupt line
As I mentioned in the second post in that issue report, it's not actually ParticleSoftSerial that's causing the problem but the fact that it uses attachInterrupt() and the problem goes away once PSS is ended which does in turn call detachInterrupt().
Sorry, missed that point. I can easily detach the interrupt before sleeping and determine what woke the Electron and attach the interrupt. Will see if that makes a difference.
I am a big fan of not building something if it already exists but, I could not find an inexpensive, low-power, i2c pressure sensor with an interrupt pin. So…
My pressure sensor is cheap and cheerful. I use two brass parts from Lowes - a 1/4 hose barb and a brass fitting. I then hot glue a rubber sheet across the fitting and attach the accelerometer to the rubber diaphragm. It works very well and these simple sensor have counted over 500,000 cars over the past three years.
The accelerometer is very low power, I build my own board so it costs about $5 and it has an interrupt so the Electron can be put to sleep to save power.
OK, back from Peru (and back to sea level!) and was able to give it a try. Detaching the interrupt before sleep and reattaching after sleep does not change the behavior.
To recap:
This code works perfectly until it does an hourly report.
After doing an hourly report, it goes into a weird mode - almost like it cannot read the status of the int2pin. It wakes from sleep on a tap, connects to Particle and then immediately disconnects. I have no idea how it is doing this given the code flow as I understand it.
The device then goes back to sleep with the int2pin HIGH so it does not wake up until the next hour.
Any ideas on troubleshooting would be appreciated.
Napping function - where I think the wheels are falling off is here:
case NAPPING_STATE: {
if (connectionMode && verboseMode && state != oldState) publishStateTransition();
stayAwake = debounce; // Ensures that we stay awake long enough to debounce a tap
if (connectionMode) disconnectFromParticle(); // If connected, we need to disconned and power down the modem
watchdogISR(); // Pet the watchdog
detachInterrupt(int2Pin); // Detach since sleep will monitor the int2Pin
int wakeInSeconds = constrain(wakeBoundary - Time.now() % wakeBoundary, 1, wakeBoundary);
System.sleep(int2Pin, RISING, wakeInSeconds); // Wake on either int2Pin or the top of the hour
if (digitalRead(int2Pin)) { // Need to test if Tap or Time woke us up
awokeFromNap = true; // This flag will allow us to bypass the debounce in the recordCount function
recordCount(); // Count the tap that awoke the device
stayAwakeTimeStamp = millis(); // Allows us to ensure we stay awake long enough to debounce
}
attachInterrupt(int2Pin,sensorISR,RISING); // Reattach Accelerometer interrupt from low to high
state = IDLE_STATE; // Back to the IDLE_STATE after a nap will come back after the stayAwake time is over
} break;
Thank you all for your help and advice.
Chip
PS, I liked the suggestion on constraining the sleep seconds. - thank you.
if the pin is already in the state you want to trigger for, the wake interrupt may not work, so wait for the pin to return to passive state before going to sleep
reconnect after sleep depends on the state of the connection prior to sleep, if it was in a limbo state before the system tends to see this as the desired state for next wake
while others seem to trust the auto-reconnect, I usually put my own connection monitoring in place and tear down the connection and manually reconnect, when I see odd behaviour
Just some personal views
Over time I came to the conclusion that it’s best to avoid #define for constant definitions wherever possible, due to their “obscure” range of scope, sometimes interfering with otherwise unrelated code.
Hence I’d replace things like this
#define VERSIONNUMBER 9 // Increment this number each time the memory map is changed
#define WORDSIZE 8 // For the Word size the number of bytes in a "word"
#define PAGESIZE 4096 // Memory size in bytes / word size - 256kb FRAM
#define HOURLYOFFSET 24 // First word of hourly counts (remember we start counts at 1)
#define HOURLYCOUNTNUMBER 4064 // used in modulo calculations - sets the # of hours stored - 256k (4096-14-2)
// First Word - 8 bytes for setting global values
#define VERSIONADDR 0x0 // Where we store the memory map version number
#define SENSITIVITYADDR 0x1 // Sensitivity for Accelerometer sensors
#define DEBOUNCEADDR 0x2 // Where we store debounce in cSec or 1/10s of a sec (ie 1.6sec is stored as 16)
#define RESETCOUNT 0x3 // This is where we keep track of how often the Electron was reset
#define TIMEZONE 0x4 // Store the local time zone data // One byte is open here
#define OPENTIMEADDR 0x5 // Hour for opening the park / store / etc - military time (e.g. 6 is 6am)
#define CLOSETIMEADDR 0x6 // Hour for closing of the park / store / etc - military time (e.g 23 is 11pm)
#define CONTROLREGISTER 0x7 // This is the control register for storing the current state
//Second and Third words bytes for storing current counts
#define CURRENTHOURLYCOUNT 0x8 // Current Hourly Count - 16 bits
#define CURRENTDAILYCOUNT 0xC // Current Daily Count - 16 bits
#define CURRENTCOUNTSTIME 0xE // Time of last count - 32 bits
#define HOURLYPOINTERADDR 0x11 // Two bytes for hourly pointer
with an enum that has an explicit scope also allowing for the use of namespaces.
Any other kinds of constants and literals I’d just define as actual const variables
#define HOURLYCOUNTOFFSET 4 // Offsets for the values in the hourly words
#define HOURLYBATTOFFSET 6 // Where the hourly battery charge is stored
// Finally, here are the variables I want to change often and pull them all together here
#define SOFTWARERELEASENUMBER "0.59"
as
const int HOURLYCOUNTOFFSET = 4; // Offsets for the values in the hourly words
const int HOURLYBATTOFFSET = 6; // Where the hourly battery charge is stored
// Finally, here are the variables I want to change often and pull them all together here
const char[] SOFTWARERELEASENUMBER = "0.59";
First, thank you for taking a look at my code and suggesting a better approach than the #defines. That section now looks like this:
namespace FRAM { // Moved to namespace instead of #define to limit scope
enum Addresses {
versionAddr =0x0, // Where we store the memory map version number
sensitivityAddr= 0x1 , // Sensitivity for Accelerometer sensors
debounceAddr= 0x2, // Where we store debounce in cSec or 1/10s of a sec (ie 1.6sec is stored as 16)
resetCountAddr =0x3 , // This is where we keep track of how often the Electron was reset
timeZoneAddr = 0x4 , // Store the local time zone data
openTimeAddr= 0x5 , // Hour for opening the park / store / etc - military time (e.g. 6 is 6am)
closeTimeAddr =0x6 , // Hour for closing of the park / store / etc - military time (e.g 23 is 11pm)
controlRegisterAddr =0x7 , // This is the control register for storing the current state
currentHourlyCountAddr =0x8 , // Current Hourly Count - 16 bits
currentDailyCountAddr =0xC , // Current Daily Count - 16 bits
currentCountsTimeAddr =0xE , // Time of last count - 32 bits
};
};
and when I need one of these values I call it using FRAM::closeTimeAddr. I understand this will reduce the chance of conflict with variable names in libraries and all. This is my first time using a namespace so, I hope I got it write - the code compiles and works anyway.
Now, onto the issue at hand. I read your issue on detachInterrupt() but I am using 0.8.0rc-4 - has this issue been addressed in the 0.8.0 release? I have tried checking the value of the interrupt pin and only going to sleep once it it low but, in the weird state it gets into, these checks don’t seem to work.
You had mentioned not trusting the auto-reconnect and that you team down the connection. What are the steps I need to take in order to try this approach?
Since I didn't see this issue getting any attention so far (not even after my bump) I doubt it was addressed yet.
However, if some dev just happened to see and squash that bug without being aware of my issue report, it could still be - worth a try with the code I provided there.
Looking at your code, it seemed that the change for me to try was to put noInterrupts() before and interrupts() after the disconnectInterrupt() command. I also added a check for the int2Pin before sleeping
case NAPPING_STATE: {
if (connectionMode && verboseMode && state != oldState) publishStateTransition();
stayAwake = debounce; // Ensures that we stay awake long enough to debounce a tap
if (connectionMode) disconnectFromParticle(); // If connected, we need to disconned and power down the modem
watchdogISR(); // Pet the watchdog
noInterrupts();
detachInterrupt(int2Pin); // Detach since sleep will monitor the int2Pin
int wakeInSeconds = constrain(wakeBoundary - Time.now() % wakeBoundary, 1, wakeBoundary);
interrupts();
if (!digitalRead(int2Pin)) System.sleep(int2Pin, RISING, wakeInSeconds); // Wake on either int2Pin or the top of the hour
if (digitalRead(int2Pin)) { // Need to test if Tap or Time woke us up
awokeFromNap = true; // This flag will allow us to bypass the debounce in the recordCount function
recordCount(); // Count the tap that awoke the device
stayAwakeTimeStamp = millis(); // Allows us to ensure we stay awake long enough to debounce
}
attachInterrupt(int2Pin,sensorISR,RISING); // Reattach Accelerometer interrupt from low to high
state = IDLE_STATE; // Back to the IDLE_STATE after a nap will come back after the stayAwake time is over
} break;
Goes to sleep and wakes on a hardware pin interrupt - no issues
Goes to sleep and wakes at the hour - does not function as expected
Connects to Particle - even though it should not
Ignores the state of the int2Pin
if the int2Pin is high, ignores the conditional that should prevent going to sleep
Goes to sleep with the int2Pin high and therefore cannot wake until the next hour
I am at my wits end with this. At this point, I have to assume there is a bug in the System.sleep(wakeUpPin, edgeTriggerMode, seconds) command or in how it is handing interrupts. I looks like my only option at this point is to give up on sleep which will have a significant impact on battery performance.
If anyone has a suggestion on what else to try, I am all ears.
Hmm, I've not looked for this particular point in your full code, but the NAPPING_STATE does only disconnect when connectionMode == true and hence if it wasn't but a connection was present, then this might play a role
This might be due to a race condition.
Allow for some more time after wake before checking the state.
When using the pin for a RISING edge trigger, the system will implicitly attach the internal pull-down resistor, which - when you don't have pinMode(int2Pin, INPUT_PULLDOWN) in your other code - needs to be removed again after wake.
BTW, checking the pin state after wake isn't a reliable way to actually know whether it was a pin wake or not - there are several threads about this topic.
