System.sleep never wakes

Firmware
1

I have an absurdly simple circuit (3.3V to 3V3, ground to GND, tactile switch between WKP and 3.3V rail), and a very simple app (posted below).

The first N times that I press the switch, the app behaves as expected. But after mashing the switch rapidly for anywhere between 5 and 45 seconds, my Photon will eventually freeze in sleep state and never wake.

This looks like a bug to me. What can I do to help figure out why this is happening, and what information can I gather to help someone debug this?

Code below. This has been substantially trimmed from the app in which I discovered the problem, but I haven’t been able to repro the problem if I trim it down even further, which (together with the non-deterministic failure behavior) suggests a timing-sensitive bug in the firmware.

SYSTEM_MODE(SEMI_AUTOMATIC);

enum Status {
    status_StartingUp,
    status_Connecting,
    status_Connected,
};

Status status = status_StartingUp;

void updateStatus(Status newStatus);

void setup() {
    pinMode(WKP, INPUT_PULLDOWN);
    pinMode(D7, OUTPUT);
    
    updateStatus(status_StartingUp);
    
    updateStatus(status_Connecting);
    Spark.connect();

    Spark.subscribe("dummy", handler, MY_DEVICES);

    // Insist on a good cloud connection
    while (!Spark.connected()) {
        delay(100);
    }
    
    updateStatus(status_Connected);

}

void loop () {
    digitalWrite(D7, HIGH);
    System.sleep(WKP, RISING, 5);
    digitalWrite(D7, LOW);
    System.sleep(WKP, RISING, 5);
}

void updateStatus(Status newStatus) {
    status = newStatus;

    switch(status) {
        case status_StartingUp: {
        } break;

        case status_Connecting: {
        } break;

        case status_Connected: {
        } break;

    }
}

void handler(const char* event, const char* message) {
}
2

@airbornemint, did you ever get this sorted out? I may be missing something, but I think there are bugs in both sleep and SEMI_AUTOMATIC that interact in some strange way. My temporary fix, illegal according to the docs, is to put SYSTEM_MODE(SEMI_AUTOMATIC); in setup() rather than before as you’re supposed to. Otherwise, most of the time my program wouldn’t even start on it’s own without this. Don’t know if that would help you or not, and it’s not a real fix. I seem to need to do this in both the latest and the current develop branches of the firmware. Like you, I’d love to know if my code is the culprit, but it’s beyond my understanding at this point.

#include "application.h"
//SYSTEM_MODE(SEMI_AUTOMATIC);
TCPClient client;
uint32_t lastTime;
char read_int;
char clientmsg = 'x';
char replymsg = '9';
byte server[] = {192, 168, 1, 157};
void setup()
{
  pinMode(D6,OUTPUT);  
  pinMode(D7,OUTPUT);
  pinMode(D3,INPUT);
  unsigned start = millis();
  while ( (millis() - start) < 10000) {Spark.process();}//while ( (millis() - start) < 1000)
SYSTEM_MODE(SEMI_AUTOMATIC);
}//setup

void loop()
{
  Spark.process();
    WiFi.disconnect();

    System.sleep(D3, RISING, 5); 

    if (digitalRead(D3)) {digitalWrite(D6,HIGH);delay(20);digitalWrite(D6,LOW);}        

    if (!WiFi.ready()) {
      WiFi.connect();
      while(WiFi.connecting()){Spark.process();}
    }//if (!WiFi.ready())
    client.connect( server, 6123);            
    if (client.connected()) {      
      byte writeReply = client.write(clientmsg);
      lastTime = millis();
      while ((!client.available()) && (millis() - lastTime < 10000)) {Spark.process();} //this is critical
      while (client.available()) { //get confirmation from server that server received msg
        read_int = client.read();
        if(read_int == replymsg ) { //we got confirmation    
          digitalWrite(D7,HIGH);delay(20);digitalWrite(D7,LOW);
          client.read();
        }//if(read_int == 9 )
      }//while (client.available())

        while (client.available() > 0 && millis() - lastTime < 1000) {
          client.read();}

      client.flush();
      client.stop(); 
    }//if (client.connected())
delay(1001);
}//loop
3

No, I have up on sleep for the time being. And I didn’t see anything pertinent in 0.4.4 release notes, so I have no reason it’s better now. That said, I do have one suggestion: if you have a clear and reproducible problem, my experience is that you will get a faster and more useful response by opening an issue on github than by posting in these forums.