Thales' cellular IoT products business is now part of Telit Cinterion, find out more.

You are here

Community > Forum > Cellular Hardware > Upgrading the JRC MIDlet as part of a FW update

Upgrading the JRC MIDlet as part of a FW update | Telit Cinterion IoT Developer Community

Like
0
5
cwolff's picture
cwolff

January 16, 2018 - 4:36pm, 3208 views

I'm looking at doing firmware updates in the field and I am trying to figure out a way to update the JRC MIDlet in a fail-safe manor.

My firmware update process goes something like this:

  1. Upload .JAD, .JAR and .USF file to modem's internal FFS using the AT^AT^SJDL=1 command
  2. Verify CRC on each file
  3. Stop currently running MIDlet (JRC MIDlet is the only one installed as I don't have any other applications installed)
  4. Install NEW JRC MIDlet over the top of the old MIDlet
  5. Start NEW JRC MIDlet
  6. Update firmware with AT^SFDL=2 command

If I power cycle during the JRC MIDlet install (step 4), the FFS appears to be inaccessible and AT^SJAM=4 reports nothing installed.

3 Questions:

  1. Am I doing something wrong in my sequence above? 
  2. Is there a way to avoid the state I am currently in and/or make my update recoverable if powercycled at step 4?
  3. Is there a way I can recover this board?
5
Comment
Log in or register to post comments
Bartłomiej Gemalto Moderator's picture
Bartłomiej Gema...
Jan 17 2018 - 11:45am

Hello,

Each JRC MIDlet version is dedicated to the corresponding firmware version. To be 100% sure that there will be no conflicts you could deactivate autostart first, then update the firmware file, uninstall previous JRC, install the new one and activate autostart.

When you power off the module during the installation the application will probably not be fully installed and there will be no app installed after the reboot.

Is it no longer possible to access the FFS and install anything? Did it happen once or does it happen each time? Generally cutting off the power is not advised - there's a big chance that nothing bad will happen but some small risk may always be there as some pending operations will not be finished in a proper way. The most advised way to reset the module is software reboot. Hardware reset should be used if there is no other possibility.

As I understand you are doing the update locally. If so you could also use the gWinSwup application that updates the firmware and JRC.

If it really happened that you cannot access FFS in any way (AT commands, MES) and you feel that something wrong has happened with it, you could try to use gWinSwup with option "Recovery File System" checked. 

What happens when you try to access the file system? Have you tried to install the MIDlet that should already be on FFS?

Regards,

Bartłomiej

cwolff's picture
cwolff
Jan 17 2018 - 3:47pm

This happens each time.  I am doing this locally now, but in the field, this update will be triggered remotely and I have to account for someone locally shutting down the machine that powers my board.  The devices in the filed will be sealed and there will be no way to update them via gWinSwup.  However, at my desk, I can tun gWinSwup and it aways fails.  I've tried every combination of checkboxes and there was no way to recover.

I did some poking around after my origional post and found the following. 

  1. I took a fresh new board off the shelf
  2. Loaded the .JAD, .JAR, and .USF files to the Gemalto FFS (for simplicity sake: JRC-1.56.58.jad, JRC-1.56.58.jar, SAM_6260.usf). 
  3. Stopped the current running MIDlet (AT^SJAM=2,"a:/JRC-1.56.30.jad","")
  4. Started the install of the MIDlet on the FFS (AT^SJAM=0,"a:/JRC-1.56.58.jad","")
  5. Before update completes, pull power
  6. Power board back up
  7. ATI1

    Cinterion
    EHS8
    REVISION 03.001
    A-REVISION 00.000.14
  8. AT^SJAM=5

    OK
  9. AT^SJAM=4

    OK
  10. AT^SFSA="ls","a:/"

    ERROR
  11. As it appears, I cannot acceess the FFS anymore because there is no MIDlet installed or running on my system (pretty neat catch 22)
  12. As stated in #2, I know what SHOULD be in the FFS even tho I have no access via AT commands
  13. Tried installing the JRC MIDlet that I believe should be located on the FFS (AT^SJAM=0,"a:/JRC-1.56.58.jad","")
  14. This command reports success
  15. At this point, I can start the MIDlet and I recovered my board.

I'm not sure if it's supposed to work like this or if I just stumbled on a nice workaround... but documentation in this area is VERY weak.

Bartłomiej Gemalto Moderator's picture
Bartłomiej Gema...
Jan 18 2018 - 10:17am

Hello,

If gWinSwup is not working maybe you use the wrong port - please use modem port or ASC0.

Some AT commands are implemented in JRC MIDlet and will return ERROR while JRC is not running. So that is probably the reason why AT^SFSA returns ERROR. But AT^SJDL command should be working and it should also be possible to access FFS with MES. 

The successful installation of JRC that had previously been stored on FFS seems to confirm that nothing bad has happened here and there is no need to make any fixing attempts. 

Most of AT commands and all the crucial ones are implemented in the firmware, so the module without running JRC is quite functional, you could not even notice that JRC is not running.

Best regards,

Baerłomiej

Paul D'Agostino's picture
Paul D'Agostino
Dec 3 2019 - 3:54pm

What does JRC stand for?

Bartłomiej Gemalto Moderator's picture
Bartłomiej Gema...
Dec 3 2019 - 4:42pm

Hello,

As you can see in the post above JRC is the MIDlet in which some of the module's AT commands are implemented. It is installed in the factory together with the firmware image and should be treated as a part of module's software. Each firmware file is released with the corresponding JRC MIDlet and both should be updated together.

The full name for JRC is Java Remote Control which in fact does not say much about what it really is. 

Without JRC running the module will still be working but its functionality will be limited and some of AT commands will just return ERROR.

I hope that it helps.

Best regards,

Bartłomiej