EHS5 module crashes after OTAP procedure | Telit Cinterion IoT Developer Community
December 9, 2020 - 10:30am, 1687 views
Hello,
Cinterion EHS5 module Rev 04.000 crashes after OTAP procedure.
This error is easy to reproduce: when OTAP procedure is in progress (10-15 seconds after the begining) you should disconnect the module from power.
The result is as follows:
1. The user midlet which was being updated is no longer present in module, only JRC midlet is running:
at^sjam=5
^SJAM: "a:/JRC-1.60.02_crn00054.04.jad","Java Remote Control MIDlet Suite","Cinterion","1.60.02",1,1
2. The most disappointing thing is that no answer for at^sjam=4 (read installed midlets). When
issue this comand there is an error in syslog port:
java.lang.NullPointerException: 0
- com.cinterion.ams.AmsNativeCommand.execute(), bci=650
- com.cinterion.ams.AmsNativeExtension$NativeCommandListenerThread.run(), bci=9
I think that JRC midlet is not working correctly.
Additional information about the revision of the module:
ati1
Cinterion
EHS5-E
REVISION 04.000
A-REVISION 01.000.05
Please answer my questions:
1. Is this a problem of JRC midlet? If so will it be solved? When OTAP procedure fails the module should recover the old midlet but not to delete it.
2. How to recover the module now?
And the last question: is it possible to install a new user midlet remotely by OTAP?
Thank you for your reply.
Hello,
Did you reproduce it more than once or on more than one module?
Did you have the OTAP tracer activated with AT^SCFG="Trace/Syslog/OTAP","1" command (OTAP tracer activates on the interface on which you enter the command and blocks it until the reboot) to see what was the status when you cut off the power?
In general OTAP should not delete the old application until the new one is downloaded successfully. But then the old one is uninstalled first and the new one installed. After all is finished regardless of the result there is a reboot which is the last step of OTAP. After reboot OTAP is not restarted or continued.
Cutting off the power is never 100% secure and it is possible that some pending operations will not be properly terminated. This exception could be a result of that.
Was the updated app enabled for autostart?
If the old app is no longer installed we may suspect that you cut off the power after (or during) it was uninstalled by OTAP and before the new one was installed or while it was being installed. I suppose that it should not be easy to hit such a moment but you somehow did.
It is possible to install a new MIDlet by OTAP in a same way as you update the existing one. So you should definitely try. Or you can also try the local installation. If you will not succeed you can try to reinstall the firmware.
Best regards,
Bartłomiej
Hello, Bartlomiej,
Yes, it was reproduced on two modules of the same firmware.
No I unfortunately didn't do it.
It turns out that OTAP operations don't seem to be secure, the worst thing is that the module ***** to be recovered locally after unsuccessfull OTAP. I understand that it is a rare situation but hoped that OTAP is more secure. May this error depend on the firmware version or revision of the module?
Autostart is enabled for all midlets.
Yes I tryed to install my midlet locally by "AT^SJAM=0" comand but it failed to be installed. Now the module don't respond to "AT^SJAM=4" comand (this comand still causes the exception on syslog port).
I also tried to install a new firmware to recover the module but with no result. I appreciate your help with recovering my modules.
Best regards,
Vitaliy
Hi,
What was the result of MIDlet installation attempt? Can you paste it? Please set AT+CMEE=2 before the attempt. Please also try to install it with OTAP (and enable OTAP tracer before that).
As for the firmware installation - gWinSwup application has an option 'Recovery File System' - please check it and try again.
Regards,
Bartłomiej
Hello!
at+cmee=2
OK
^SYSINFO: 200
at^sjam=0,"a:/TU41sm.jad",""
+CME ERROR: Unknown
at^sjam=5
OK
at^sjam=0"a:/JRC-1.60.02.jad",""
+CME ERROR: operation not supported
at^sjam=0,"a:/TU41sm.jad",""
+CME ERROR: Unknown
at^sjam=0,"a:/JRC-1.60.02.jad",""
OK
at^sjam=0,"a/TU41sm.jad",""
+CME ERROR: Unknown
I have never tried to install a user midlet by OTAP. So I'd better try local installation if it is possible.
Here is a log from "ehsx_gwinswup_rev04.013_arn0100006.exe" with "Recovery file system" check (connection to ASC0 port):
[2020-12-14 10:12:20]
[2020-12-14 10:12:23]OpenAttachedFile: No. 13 file not exist
[2020-12-14 10:12:23]Disabling userware autostart...
[2020-12-14 10:12:23]Checking module Character Set ('GSM' or 'UCS2') ...
[2020-12-14 10:12:41]INFO: Original baudrate = 115200
[2020-12-14 10:12:42]Restoring module state...
[2020-12-14 10:12:50]Initializing firmware update...
[2020-12-14 10:12:52]INFO: Original FlowControl = 0
[2020-12-14 10:12:55]Erasing flash memory (this can take a couple of minutes without visible progress)...
[2020-12-14 10:12:55]ERROR: Unexpected or fatal response (0x00) to block 0!
[2020-12-14 10:12:55]ERROR: Firmware update failed!
[2020-12-14 10:12:55]Parsing configuration file...
[2020-12-14 10:12:55]Restoring module state...
[2020-12-14 10:12:55]Module update failed
What else could I do to recover my module?
Hello,
According to log the old firmware was deleted and loading the new one failed at start.
You did it on serial - do you have all the lines connected, especially RTS/CTS lines? Please try on USB ****m port.
Honestly I don't think that it has anything to do with your previous problems. It's rather related to your setup.
If there is no valid firmware in the module it boots in the firmware download ****. So gWinSwup can be started after reboot (with the option "No Firmware in Module" checked). For the first 10 seconds it can be started on ASC0. After that the module should enumerate on USB and fhe firmware update can be start on USB.
Regards,
Bartłomiej