Roaming networks with AT+COPS


We’re using roaming data SIM cards so when we have problems connecting via one network we roam to the next available network in an attempt to re-establish communications. Our application is based on the FXT009 on FW 7.51.

We use AT+COPS=4,2,MCCMNC command called via adl_atCmdCreate to roam to another network after failure to open the bearer or establish a connection to our server after several attempts.

We also use the level3 library to find the list of available networks.

This roaming functionality means that during network failures at our SIM card provider our application can request roaming continuously between networks until the fault is resolved at our SIM card provider.

This works 99% of the time and our application is able to re-establish communications after a few minutes or hours.

However, 1% of the time the AT+COPS command never returns to our AT response handler and any attempts to open the bearer hangs and never connects. It would appear that the embedded modem has crashed? Hung? Or the AT command handler is waiting for the last call to return?

We have our own watch dog timer and if communications cannot be re-established after a few hours we restart the board with AT+CFUN=1, again using adl_atCmdCreate. Which normally works fine, however when the above situation occurs and the AT+COPS command never returns this AT+CFUN command is not executed. If we visit the site affected and call AT+CFUN=4 on the local USB port, this causes the board to recover the the AT+CFUN command is executed.

Has anyone else experienced this behavior and have a fix? Our current work around is once we have requested a restart with AT+CFUN=1 we then set another 10 minute timer, if this timer is triggered and a restart hasn’t occurred then we force a reset with adl_errHalt which does work.

Thanks for any help you can provide.

I guess the network condition is not good and for same reason +COPS keeps trying…

Not sure does this help… Have you tried sending abort command (AT+WAC) when +COPS is not responding?

In some case PLMN selection may takes long and +WAC was here for this case, refer to AT cmd guide, this command allow SMS, SS and PLMN selection related commands to be aborted.

In such case, it should at least, allow your OpenAT app to grant access to the internal AT port so you can later retry or check the network status.

Hope this helps.


Another (quick and dirty) way to force the module to restart is to simply do a


This will cause a watchdog timeout and restart the module.
You can check to see how/why the module started by checking the result of



ciao, Dave

A nicer way to force a reboot would be adl_errHalt() - which can also place diagnostic information into the backtrace for debugging…

Does the reboot due to AT+WRST still work on a unit in this state?

Thanks lotam, I will give that a try. This issue only occurs rarely so will take a few weeks to be able to test using the AT+WAC command.

AT+WRST command looks useful but not in our case as our watch dog timer saves our application’s state and any information which hasn’t been communicated to the flash before restarting so it looks like adl_errHalt is the best way to force the restart in our case. Although I’m keen to try the AT+WAC command and see if that allows our application to recover without a restart.

It appears as though in this state the internal AT command handler is blocked waiting for the AT+COPS command to return so any AT commands cannot be called in this state, hence the call to adl_errHalt does work as it doesn’t use the AT command handler.