BGS5 - JAVA midlet on v02.000 locks up | Telit Cinterion IoT Developer Community
June 20, 2018 - 12:23pm, 2862 views
Dear support,
we've been using the previous hardware revision for a couple of years now with success. Now that the new hardware revision is out, we have to check if everything still works. To our surprise, it does not, there is a difference in midlet behavior between the previous hardware revision and this one.
We're using the latest WDK as that was suggested elsewhere:
WTK Version : "REVISION 02.000"
Date of WTK generation: 20.7.2017
The issue we face is that an ATCommand.send, both synchronous and asynchronous version, completely locks up and doesn't return an answer.
This ONLY happens on the first execution of the midlet, once the midlet is stopped (at^sjam=2) and started again (at^sjam=1), everything works fine. Needless to say that this kills the autostart functionality.
There also appears to be a relation between a delay between the ATCommand constructor call and the .send call. When that delay is not present, it appears to return an answer in some executions, when that delay is present, it fails 100%. I've added the delay to simulate the creation of a singleton atcommandhandler and the usage of that handler in some point in time.
When it is in the 'hanging'state, also terminal commands respond terebly slow.
^SCFG: "Call/ECC","0"
^SCFG: "GPRS/AutoAttach","enabled"
^SCFG: "Gpio/mode/ASC1","gpio"
^SCFG: "Gpio/mode/DAI","gpio"
^SCFG: "Gpio/mode/DCD0","std"
^SCFG: "Gpio/mode/DSR0","std"
^SCFG: "Gpio/mode/DTR0","std"
^SCFG: "Gpio/mode/FSR","gpio"
^SCFG: "Gpio/mode/PULSE","gpio"
^SCFG: "Gpio/mode/PWM","gpio"
^SCFG: "Gpio/mode/RING0","std"
^SCFG: "Gpio/mode/SPI","gpio"
^SCFG: "Gpio/mode/SYNC","gpio"
^SCFG: "Ident/Manufacturer","Cinterion"
^SCFG: "Ident/Product","BGS5"
^SCFG: "MEShutdown/Fso","0"
^SCFG: "MEopMode/SoR","on"
^SCFG: "Radio/Band","15"
^SCFG: "Radio/OutputPowerReduction","4"
^SCFG: "Serial/Interface/Allocation","0","0"
^SCFG: "Serial/USB/DDD","0","0","0409","1E2D","0059","Cinterion Wireless Modules","Cinterion BGx USB Com Port",""
^SCFG: "Tcp/IRT","3"
^SCFG: "Tcp/MR","10"
^SCFG: "Tcp/OT","6000"
^SCFG: "Tcp/WithURCs","on"
^SCFG: "Trace/Syslog/Otap","0"
^SCFG: "URC/Ringline","local"
^SCFG: "URC/Ringline/ActiveTime","2"
^SCFG: "Userware/Autostart","1"
^SCFG: "Userware/Autostart/Delay","0"
^SCFG: "Userware/Jamfile/Chkinterval","12"
^SCFG: "Userware/Jamfile/Chkrcvy","0"
^SCFG: "Userware/Passwd",
^SCFG: "Userware/Passwd2",
^SCFG: "Userware/Stdout","usb1",,,,"on"
^SCFG: "Userware/Watchdog","0"
ati1
Cinterion
BGS5
REVISION 02.000
A-REVISION 01.001.06
I've managed to isolate the issue we have in a midlet of 80 lines of code, which I'm happy to share but effectively it boils down to this:
ATCommand command = new ATCommand(false);
System.out.println("Waiting for 25 seconds");
Thread.sleep(25000);
System.out.println("About to send command");
if (synchronous) {
String response = command.send("at^sjam=4\r");
System.out.println("Received response " + response);
}
else {
answered = false;
command.send("at^sjam=4\r", listener);
System.out.println("Sent command, waiting for answer");
synchronized(lock) {
if (!answered) lock.wait();
}
}
System.out.println("Release atcommand");
command.release();
One addition, we tested this midlet on 2 different BGS5 chips and they both reacted the same.
Hello,
The case that you describe is quite strange that the problem is only when there's no delay between instance creation and command execution. The first thing to check would be if you are using the correct libraries for this module - it looks like you are.
Have you also tried to create more ATCommand() instances in one MIDlet - is there a problem for all of them?
By "This ONLY happens on the first execution of the midlet" you mean that this happens each time after the module is restarted or only once after MIDlet installation? If it is each time after reboot then the question is do you have the proper code in destroyApp() to release the resources and is startApp() already left when you stop the MIDlet?
If that would happen only if you use autostart we could check if Oracle-MIDlet-Autostart in the jad file is set to a value greater than 1 to let JRC start first. And we could add some delay inside the application before creating ATCommand instance or even before execution any application logic just to check if there is any difference. You have written that after stopping the MIDlet started automatically and manual start it works fine. How about if it's not enabled for autostart at all and you start it manually when the module is already up for some time?
Best regards,
Bartłomiej
Hello,
According to your description the problem occurs when you create the first ATCommand instance. Then you close the MIDlet and start it again, another ATCommand instance is created and that one is working fine (I don't know if the first one is released in you destroyApp()). That's why I have asked you to check with more than one instance in one MIDlet.
Nevertheless if you have double checked and you are sure that all the libraries are correct for the product and have tested with MIDlet that only does this simple scenario, then it looks like a faulty behavior. Unfortunately I can't see this revision 2 firmware in official releases yet and don't have this hardware to test. So I think that you should report this to your local Gemalto technical sales who has provided you with the module and it should be forwarded to Gemalto technical support for further investigation and tests.
Regards,
Bartłomiej
Finally I unravelled the mystery. The problem is caused by Eclipse, where it stores a local copy of the cwmlib_1.0.jar file in a folder called “C:\Users\Public\Eclipse\{Workspace}\{Project}\.mtj.tmp\verified\libs\cwmlib_1.0.jar”. This jar file was still of the previous WTK, even though I deleted that completely from Program Files.
Since it was verified, Eclipse didn’t bother to use the updated cwmlib_1.0.jar. Also creating a new project in the same workspace resulted in re-using that same verified cwmlib instead of using the one located in Program Files.
I found another location where the old cwmlib was at “C:\Users\{username}\AppData\Local\VirtualStore\Program Files (x86)\Cinterion\CMTK\BGS5\WTK\resources” which was also the wrong one. I deleted that too.
After fixing both locations, the new cwmlib was copied from Program Files and included in my Midlet. After that, the Midlet correctly works and doesn’t deadlock anymore.