B524 freezes after being woken up by GPIO during ULTRA_LOW_POWER sleep

Firmware
1

Hello,

I have a weird issue/bug where I use the following code for sleeping (I have a hall effect sensor that can wake the device up prematurely from sleep):

/**
    Sleep function between measurements
    @param measurementDelay The time it takes to conduct a measurement
    @param networkStandby Whether the device should put modem on standby during sleep
*/
void Class:measurementSleep(int measurementDelay, std::chrono::seconds measurementSleepTime, bool hallEnabled)
{
   Class::instance().setPanicCode(234);
   // Initialize Power Configuration
   SystemSleepConfiguration measurementSleepConfig;
   // Power Configuration using ULTRA_LOW_POWER, HALL_PIN for restart and compensated sleep duration - SystemSleepMode::ULTRA_LOW_POWER
   measurementSleepConfig.mode(SystemSleepMode::ULTRA_LOW_POWER).duration(Class::instance().getCompensatedSleepTime(measurementDelay, measurementSleepTime));

   Class::instance().setPanicCode(239);
   if (hallEnabled)
   {
      measurementSleepConfig.gpio(IOConstants::HALL_PIN, CHANGE);
   }
   Class::instance().setPanicCode(244);
   // Handle network standby for cellular interface based on constants or time limit
   if (Class::instance().getNetworkStandby()) // (measurementSleepTime.count() * Class::instance().getNumberOfMeasurements()) < CloudConstants::NETWORK_STANDBY_LIMIT)
   {
      Class::instance().setPanicCode(248);
      classLogger.info("Setting network to standby");
      measurementSleepConfig.network(NETWORK_INTERFACE_CELLULAR, SystemSleepNetworkFlag::INACTIVE_STANDBY);
   }
   Class::instance().setPanicCode(25200);

   // Do one last system/watchdog checkin
   Class::instance().systemCheckin();
   
   // Execute SystemSleepConfiguration and enter sleep
   SystemSleepResult result = System.sleep(measurementSleepConfig);
   Class::instance().setPanicCode(256);

   // If device was woken up due to hall effect being triggered
   if (result.wakeupReason() == SystemSleepWakeupReason::BY_GPIO)
   {
      Class::instance().setPanicCode(260);
      delay(500);
      classLogger.info("Device was woken up by hall effect sensor");
      // Hall sensor was triggered during sleep, so let's restart!
      System.reset(RESET_APP_ENUM::HALL_MEASUREMENT_SLEEP, RESET_NO_WAIT);
   }
   Class::instance().setPanicCode(264);
}

I have the device hooked up to my computer, so I can see that the serial monitor suddenly opens up, but the device doesn't progress with any other tasks, it simply 'hangs'/freezes until the watchdog timer triggers and the device resets, whereas I get the following event:

HALL_MEASUREMENT_SLEEP_25200
or
HARDWARE_WATCHDOG_25200

Which means that the device was reset due to the hall effect sensor or watchdog being triggered when sleeping and the last panic code being set is 25200 (the code just before the System.sleep command), which means it doesn't run the following code:

   // If device was woken up due to hall effect being triggered
   if (result.wakeupReason() == SystemSleepWakeupReason::BY_GPIO)
   {
      Class::instance().setPanicCode(260);
      delay(500);
      classLogger.info("Device was woken up by hall effect sensor");
      // Hall sensor was triggered during sleep, so let's restart!
      System.reset(RESET_APP_ENUM::HALL_MEASUREMENT_SLEEP, RESET_NO_WAIT);
   }

It freezes right after it wakes up, and not even the line after SystemSleepResult result = System.sleep(measurementSleepConfig); is executed.

I have no idea what is happening, this is happening on both DeviceOS 5.3.2 and DeviceOS 5.5.0

2

It's not at all obvious what might be happening here.

What is the status LED showing during the time waiting for the watchdog?

If you have the hardware UART (RX/TX) available on your board and have a 3.3V TTL to USB serial converter (FT232) you might want to try enabling the Serial1LogHandler and monitoring the FT232 debug serial. This is better than the USB debug serial because the Serial1 debug does not disconnect when the device goes to sleep and you're more likely to get more interesting log messages right after wake. But you're still not guaranteed to get anything.

If that's not possible, I'd keep adding more debugging statements around the problem section.

I presume you didn't populate the SWD pogo pins on your board, so worst case you may need to try to reproduce this on the M.2 SoM eval board with a CMSIS/DAP debugger so you can MCU halt and bt to see where the code is actually looping.

3

Thanks @rickkas7 - I'll try to switching it to a eval board and connect via a debugger and get back with updates!

4

As I've haven't been able to get the Particle Debugger to work, I've used the old method of elimination.

What I've found is that the Beaconscanner library is the culprit, I suspect it has something to do with either BLE or Thread-use in the library. If I comment out 'startContinuous', then it runs stable. I am unsure how the thread or BLE effects the wake-up after sleep however.

The LED is showing a white light when it wakes up and waits for the hardware watchdog timer to kick in.

5

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.