-
Notifications
You must be signed in to change notification settings - Fork 511
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Electron] Workaround for modem HAL relying on system networking code to re-attempt initialization #2218
Conversation
7ee3589
to
93163c4
Compare
93163c4
to
6ddf553
Compare
0385a79
to
66bc610
Compare
The test # 2 fails for me when I call |
@@ -773,6 +825,12 @@ class ManagedNetworkInterface : public NetworkInterface | |||
|
|||
virtual int process() | |||
{ | |||
// Requested to power-on, failed initial power-on, requested to connect as well | |||
if ((SPARK_WLAN_STARTED && !WLAN_INITIALIZED) && WLAN_CONNECTING) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See this comment.
Also, wouldn't this change affect Photon/P1 as well, contrary to what is stated in the PR description?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose this condition wouldn't happen on Photons. And even if it does, it won't probably hurt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We discussed the issue described in the comment and decided that we're not going to fix it in the scope of this PR as there's a risk of introducing a breaking change in the release.
Problem
There are two problems which have some common roots. If the power-on sequence on Electrons fails (and there are two stages in it: power on and SIM initialization, additional initialization), a specific set of actions needs to be taken by the system networking layer to get the modem HAL into a proper state.
MDMParser::init()
fails to initialize and requires a modem reset e.g. to set UMNO profile. This used to work somewhat until we've introduced reliable modem power off in one of the Sleep 2.0 PRs, which now causes the modem to be hard powercycled almost immediately after we've reset it through an AT command.MDMParser::init()
) was skipped whenever initial SIM initialization inMDMParser::powerOn()
failed, because for some reason reinitialization is happening inhas_credentials()
(see https://app.clubhouse.io/particle/story/64669, https://app.clubhouse.io/particle/story/64668)
Solution
Add even more hacks! Ideally all these retries should be contained with the modem code and spread through multiple subsystems but this potentially brings some behavior changes, which we shouldn't be making so far along into LTS.
The main idea behind this PR is to check whether power-on succeeded and if not, rely on [
network_connect()
] (https://github.com/particle-iot/device-os/blob/develop/system/src/system_network_compat.cpp#L262) to trigger reinitialization.Steps to Test
Here are a few patches to trigger a particular issue:
MDMParser::init()
failing, to emulate a case where we need a reset to set e.g. a correct UMNO profile:There should be 8 attempts made to run
MDMParser::init()
and after that the system should continue to attempt to registerMDMParser::powerOn()
failing due to SIM failureThis should trigger the system to enter listening mode as if the SIM card is not present and after 5 minutes (default listening mode timeout), the device should connect to the network.
MDMParser::powerOn()
failing due to SIM failure (similar to the previous one, but we fail only once)The device should report SIM failure once and then go through
MDMParser::init()
and successfully connect.This should cause a modem reset in 5 minutes and restart the initialization again.
Example App
N/A
References
Completeness