[gen2, threading] Fixes Cellular taking up to 10 minutes to shutoff modem with Cellular.off() / System.sleep(config) if there is no cell connection [ch73242]

[technobly]

Problem

On Gen 2, with Threading enabled, Cellular.off() can take up to 10 minutes when there is no cellular reception and the device is actively trying to connect to cellular. This is due to the registration timeout of 10 minutes and the cellular_cancel() request not being processed.

The Sleep 2.0 API also has a similar issue and can cause the device to take a long time to enter sleep or other powered down states.

Gen 3 devices are not affected.

Solution

A flag in system_network_cellular.h called connect_cancelled was not being reset to false when cellular_cancel() was being called false to unconditionally resume the AT interface. This has been fixed.

Sleep 2.0 calls (i.e. System.sleep(config);) have been prepended with a network_connect_cancel if network_connecting is true.

Sleep 2.0 tests were also updated for better reliability running in threaded mode.

Workaround

As a workaround, a user may call cellular_cancel(true, false, NULL) before Cellular.off() / System.sleep(config)

Workaround for Cellular.off()

cellular_cancel(true, false, NULL); // Workaround: call before Cellular.off()
Cellular.off();

Workaround for System.sleep(config);

cellular_cancel(true, false, NULL); // Workaround: call before System.sleep(config)
SystemSleepConfiguration config;
config.mode(SystemSleepMode::HIBERNATE);
SystemSleepResult result = System.sleep(config);

Steps to Test

TEST=wiring/cellular_no_antenna
TEST=wiring/sleep20
Tested on Electron G350/ E Series LTE/3G / Boron LTE

References

ch73242

---

Completeness

• User is totes amazing for contributing!
• Contributor has signed CLA (Info here)
• Problem and Solution clearly stated
• Run unit/integration/application tests on device
• N/A Added documentation
• Added to CHANGELOG.md after merging (add links to docs and issues)

[avtolstoy]

@technobly I know the original issue was about Cellular.off() specifically, but the main context was sleep. This still does not solve the problem for a case where the user application is relying on sleep APIs to do the right thing and entering sleep mode will also be postponed by 10 minutes. This is due to the fact that sleep APIs are executed on system thread https://github.com/particle-iot/device-os/blob/develop/system/src/system_sleep.cpp#L86 which will be blocked in the registration loop.

Do we want to do something about that?

[technobly]

@avtolstoy I didn't see that specific reproduced case in the CH story, but yes of course we should fix that. Let me add a test to reproduce it first (CELLULAR_NO_ANTENNA_03_device_will_sleep_quickly_when_modem_cannot_connect). Any suggestions for a fix are welcome.

[avtolstoy]

@technobly Ideally we'd refactor the modem code to not block the system loop while registering, but that requires quite a bit of acrobatics to achieve as there are things like AT command timeouts to consider (e.g. COPS taking 5 mins etc). As a quick workaround I would perhaps add a fix specifically for Electron to check for network_connecting in system sleep APIs (system_sleep_ext()) and force a cancellation before attempting to schedule sleep method execution on system thread (EDIT: that's actually what we already in Sleep 1.0 system APIs)