Remote Update FW and Open AT App together via AV Portal?

Connectivity and Cloud Services Device Management
1

Hello,

We are developing an Open AT App for SL6087. Current version is based on FW 7.51 but our new version requires 7.52.

Is there a way to bundle the Open AT App and the FW together in one package so that we can securely and robustly update our devices via the AirVantage portal? (Handling error conditions with complete rollbacks)

Thanks

2

Topic moved to the correct section…

3

Hi Eric,

it’s not possible to merge the two applications.
What you can do, it is to prepare two operations on AV Portal, one for the FW first, a second one for the software. The two operations will be managed one after the other.

Regards.

4

Hi Robert,

That was the first thing we tried. We are starting to get to the root cause of the problem.

We think the problem is related with using a private APN.

Our AT App normally sets up a PDP Context and to communicates with our server. For an Update:

  1. The server sends the (custom) command to the modem App and the APP issues an AT+WDSS.
  2. Our security configurations require the current PDP Context to be deactivated and a new one to be setup to connect to the AV Portal. So the new context is activated.
  3. We see from the portal the F/W 7.52 is successfully downloaded to the device. (Also confirm from Developer Studio traces)
  4. The device seems to loose connection to the portal before reporting that it is successfully updated and tries to reconnect to the APN. Maybe this is a normal F/W update behaviour I’m not sure.
  5. The device gets an invalid username/password for our APN from the network.

And since it cannot reconnect to the portal again it cannot report that it installed the F/W and cannot get/start the next operation (New App Version Update).

We can confirm that the device successfully updates itself from Developer Studio. So the update goes fine than cannot connect (create PDP context) to our APN anymore.

Regards,

5

Eric,

This is the normal FW upgrade. Once the binary has been downloaded, the device switches in install mode and install the binary. Then it reboots and does a new communication to send acknowledgement (send the new FW version) to the server.
What’s going wrong it’s the step 5:

What do you mean by that ?
What I understood, your device should continue to use the new APN.

By the way, the device uses two “registers” to define APN. One for the customer application: cgdcont, one for the FW, wdss. If wdss is empty, the cgdcont is used.

So what I understood, you just need to set the wdss APN:
at+wdss=0,“<your_public_apn>”

Regards.

6

Hi Robert,

We use a private APN, not a public one.

After the new firmware is downloaded and installed the device cannot connect to our private APN anymore.

I ran a AT+WDSS=1,1 which reported me CME Error 149 which is PDP Authentication Error.

So I ran a AT+WDSS? to see the current values. The result was:

+WDSS: 0,"",""
+WDSS: 1,0
+WDSS: 2,0

Than I tried to set the APN values manually:

AT+WDSS=0,"","","”

After that tried again an AT+WDSS=1,1 and it successfully connected back to the AV portal and proceeded with the rest of the pending operations.

Seems like the password for the APN disappears but the rest of the settings stay during a F/W update.

Why do you think this happens? Is there a bug/issue/limitation with updating firmwares in a private APN configuration?

Regards,

7

Hello,

It seems the issue cause is not the remote upgrade with AirVantage but from the firmware.
It sounds like an issue or limitation from the Firmware.

We will try to reproduce your issue but perhaps someone more aware about firmware can help you on this forum?

Regards.

8

Hi Robert,

We need to update devices till the end of this month so it is important for us to find a way to resolve this issue.

Were you able to come up with something? Do you need any help/data from me?

Regards,