Corrupt MIDlet Jar Files | Telit Cinterion IoT Developer Community
January 5, 2017 - 2:20pm, 4832 views
we recently experienced two different cases of ******* MIDlet jar files:
First case was a broken jar file of our own custom MIDlet. We checked AT^SFSA="stat","..." and AT^SFSA="crc","..." and discovered a correct file size, but wrong CRC value. After replacement of the jar file, the terminal worked alright again.
Second case was a broken JRC midlet file: The terminal just gave output "^SYSINFO: 201" after boot and restarted afterwards, thus was stuck in a restart loop. (AT Command Set explanation: "The JRC midlet was started, but did not succeed to full init itself within a (JRC midlet defined) timeout. 5 seconds after this URC, the module will restart.") After having flashed the terminal it now seems to work alright again.
Now my questions:
1. How come all of a sudden installed midlet jars become ******* resulting in a situation where terminals need to be replaced by a technician at the customer's place, since no other option (e.g. OTAP) would work any more?
2. Are there ways and methods to prevent MIDlet jars from becoming *******? We do not change the MIDlet itself, it's written once during configuration phase and then delivered to the customer. However, our MIDlet reads from and writes to the flash file system.
3. Are there other people here who experienced *******ion of MIDlet jar files?
Edit: I should have mentioned it's about BGS5 based terminals.
Thanks for your answers!
Was the application working fine before the problem was detected?
When the MIDlet is installed it is copied to the separate hidden space on the flash file system and the jad and jar files that were used for the installation can be deleted from the file system. With SFSA command you were able to check the CRC of the files on public file system and not the installed MIDlet. So it could be also possible that the file was corrupted before copying to FFS.
But in case of JRC the MIDlet was probably corrupted after installation.
It's hard to say why that happened or how to prevent it. One thing that comes to my mind is how you turn on and off the module - are you using the software methods to shut down the module (for example AT^SMSO command) or just cut off the power. It is recommended to always try the software switch-off first as in other cases there is always some risk that some operations may not be properly finalized.
If the application is extensively using the FFS maybe that could have been the reason.
thanks for your fast reply!
Yes, the application worked alright before the problem was detected.
We know that applications are copied to some separate hidden space on the file system during the installation process, but we also know how to check the CRC of files within that space and did the check this way.
In our application the power source is a battery, charged by a solar panel. It may happen e.g. during long cloudy periods that the terminal shuts down due to insufficient power supply. We do not make use of the software shutdown at all, since our application is always-on.
Our application makes no extensive use of the FFS: Every 5 minutes it performs some read and write operation. All FFS operation is done within the user space. There is no file manipulation which should affect applications within the hidden space, except OTAP on rare occasions.
We understand that installed jar files may be corrupted in cases where power is cut off just during a write operation. But, once installed, the application jar file should never be changed during the whole terminal lifetime (except of OTAP of cource). Thus, it's not clear to us how those hidden space FFS blocks the application was installed to, would be affected by any write operation.
What do you think? Are there other users here experiencing problems with corrupted jar files?
So it seems that the source of the problem was rather not the brutal power cut off.
I also don't think that the installed applications are or should be overwritten during the normal operation.
As I understand there were just 2 separate cases discovered so far and it's not happening on a regular basis. So it's hard to say what could have happened. So far there is no rule for this scenario. Was it the same terminal? Are these the Gemalto terminals or some proprietary hardware? How about the devices mounting environment - anything special like high or low temperature, humidity etc.?
thanks again for your quick answer!
Right now, we have just a few BGS5-based terminals operational at customers' places, since we just finished implementing our technology switch from EGS5 to BGS5. Thus, at the moment we just cannot state if it happens on a regular basis.
The mentioned BGS5-based terminals which suffered from MIDlet jar curruption (probably different ones, but not sure) were luckily based at our headquarter, so we were able to fix them. Nevertheless these cases startled us a bit.
The terminals are not directly made by Gemalto.
They are mounted within a solar panel housing, thus sheltered from rain, apart from that under outdoor conditions e.g. regarding the temperatures.
So the mounting place is special, because in some conditions the temperatures may probably be very high. But I also suppose that you have measured the possible temperatures and compared it with the product documentation.
If the problem occurred in the office or the temperatures are not extreme it was probably not the case here.
I think that it would be good to store the information in which terminal the problem occurred (in case it happens again) just to verify if it is always the same terminal.
As I understand the terminals were manufactured and provided by the third party company and you probably integrate it with the solar panels.
It would be worth asking them if they have heard of such a case.
in both cases the temperatures were not extremely high or low. We checked the documentation, which states the terminal is approved for extended temperature range.
Since nobody else reported similar experiences with ******* MIDlet files, I assume this have been isolated cases.
Thanks for your answers.
OK, let's treat it as incidental case.
I hope that there will be no reason to continue this thread.