Gemalto is now part of the Thales Group, find out more.

You are here

Corrupt MIDlet Jar Files | Thales IoT Developer Community

January 5, 2017 - 2:20pm, 4708 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!
Best regards!