Upgrading the JRC MIDlet as part of a FW update | Telit Cinterion IoT Developer Community
January 16, 2018 - 4:36pm, 3189 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:
- Upload .JAD, .JAR and .USF file to modem's internal FFS using the AT^AT^SJDL=1 command
- Verify CRC on each file
- Stop currently running MIDlet (JRC MIDlet is the only one installed as I don't have any other applications installed)
- Install NEW JRC MIDlet over the top of the old MIDlet
- Start NEW JRC MIDlet
- 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.
- Am I doing something wrong in my sequence above?
- Is there a way to avoid the state I am currently in and/or make my update recoverable if powercycled at step 4?
- Is there a way I can recover this board?
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?
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.
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.
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.
What does JRC stand for?
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.