Hello, The Particle firmware connection process has a major bug in it. (I’m running firmware version release/v0.6.2) If you call Cellular.disconnect() and then Cellular.off() while the Electron is attempting to register to the cellular network, it breaks the Particle connection state machine. A s…

Hi @jaza_tom Have you tried using waitUntil(Cellular.ready); to avoid this problem? Isn’t that the sort of thing that waitUntil was created for?

@bko The problem is that Cellular.ready() never occurs, therefore waitUntil(Cellular.ready) would block forever. I have a modem that I’m trying to get connected but it can’t register to the network. So I am trying to detect that when it happens and change the RAT (i.e. change from 2G to 3G or vic…

@jaza_tom , is this only a typo or have you tried waitUntil(Cellular.ready()) with the parentheses? If so, you need to leave them off - waitUntil(Cellular.ready)

OK great, but the delay(10000) and delay(5000) are just guesses and can be wrong too. I don’t know to solve your problem but I can state for sure that you are not programming in a defensive manner that tries to avoid problems. You should at least use waitFor(condition,timeout); For instance, the …

One thing I have learnt of BDub is that a Cellular.connect() is allowed to take up to 5 (five!) minutes - which makes testing such issues a pain :stuck_out_tongue_closed_eyes:

@ScruffR @bko Let me re-iterate the problem: In instances where the network never registers, I need a way to abort the Particle firmware’s network registration process ( [Modem::register] process) so that I can use AT commands to force the radio access technology to a different type (i.e. from 2G …

I believed you when you said it would loop forever, that is why I suggested waitFor() with a much larger timeout (120 seconds at least). I think you should try figure out what part of the public API does the thing you want to do in this unforseen use-case. I might try using threading and go into a…

@bko I had a similar thought about using retained variables and using System.reset() to nuke the Particle firmware state machines. I’ll give it a try tomorrow! The entering/exiting listening mode is a good suggestion too. I’ll try that as well and report back. I think you’re right about the tit…

Thanks @jaza_tom for the post! I’ll loop in some folks from our embedded development team to investigate, though we’re currently a bit underwater and might not be able to take steps to validate / reproduce immediately. Thank you for the well-documented and communicated feedback.

#Update: Using System.sleep(10) to abort the network registration process results in same bug described above. Using System.sleep(D4, CHANGE, 10); to abort the network registration process results in Electron never waking from sleep with either a pin interrupt or the timer! This seems like a …

Particle connection process - Modem::cancel bug if modem registration aborted

Firmware

jaza_tom May 25, 2017, 2:42pm 11

#Update:

Using System.sleep(10) to abort the network registration process results in same bug described above.
Using System.sleep(D4, CHANGE, 10); to abort the network registration process results in Electron never waking from sleep with either a pin interrupt or the timer!
This seems like a major bug!
_
I have started a new thread about this bug here:

Topic		Replies	Views
Electron not waking from sleep if connection process is aborted Firmware	0	1401	May 25, 2017
How to totally reset the connection process state machine Firmware	0	903	May 24, 2017
How to handle Cellular connection loss on Electron Troubleshooting	10	3993	April 27, 2017
Electron reconnection to cell service Troubleshooting	16	3300	December 1, 2018
Cellular.connect() does not connect after Cellular.disconnect() without first calling Cellular.off and Cellular.on Firmware	0	819	May 1, 2018

Particle connection process - Modem::cancel bug if modem registration aborted

Related topics