PLS62 ATCommand.send() sometimes not returning | Thales IoT Developer Community
September 30, 2021 - 10:37am, 925 views
Hi!
We noticed that every once in a while our midlet fails to execute properly due to "AT^SLED=2\r\n" not properly executing, thereby never returning anything.
Our midlet is auto-started, using the following parameters in the associated jad-File:
Oracle-MIDlet-Autostart: 2
Oracle-MIDlet-Restart: true
Oracle-MIDlet-Restart-Count: 3
The problem can be reproduced using the following code with above parameters in the jad file, but only seems to occur randomly once in a while:
public static String sendATcmd(String cmd) throws ATCommandFailedException {
ATCommand atc = null;
try {
atc = new ATCommand(false);
//atc.send("AT^SMSO\r\n");
cmd = new StringBuffer(cmd).append("\r\n").toString();
System.out.println(cmd);
return atc.send(cmd);
} catch (ATCommandFailedException ex) {
ex.printStackTrace();
throw ex;
} finally {
if (atc != null) {
try {
atc.release();
} catch (IllegalStateException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
atc = null;
}
}
}
protected void startApp() throws MIDletStateChangeException {
try {
sendATcmd("AT^SLED=2");
} catch (ATCommandFailedException ex) {
ex.printStackTrace();
}
System.out.println("Thread.sleep(60000)");
try {
Thread.sleep(60000);
} catch (InterruptedException ex) {
ex.printStackTrace();
}
try {
sendATcmd("AT+CFUN=1,1");
} catch (ATCommandFailedException ex) {
ex.printStackTrace();
}
}
Is this a known issue and what can we do to avoid this?
Thanks and best Regards,
Christopher
Hello,
It's nothing known to me.
Could you share the firmware version?
How much time can it take to reproduce this in such a simple scenario?
As I understand this happens on the first command executed on start. How is it in your real MIDlet? Is it the same or does it happen in random places?
If it happened on MIDlet start only the first thing that comes to my mind would be to try to add some delay before the command is executed.
Best regards,
Bartłomiej
Hi Bartłomiej!
Yea, it's basically exactly the same: i analyzed the propblem a bit and noticed that it always happened at the start, right when we called this AT-Command in exactly the same manner.
I just simplified it and reduced the test-software to the relevant part, which is what i posted above.
If you let it run like this, it should occur within the first 60 automatic reboots / within the first hour.
regarding the fw-version:
Hello,
I was able to reproduce the issue. Then I added 500ms before the first command execution and left the module overnight. It's still running - the problem did not reproduce since yesterday.
I think that it is related to some initializations inside the JRC MIDlet which starts just before the user applications. Probably not all is finished when your app sends the first command just on start.
In general AT commands should not be executed before ^SYSSTART is displayed (module throws ^SYSLOADING after booting and later ^SYSSTART when JRC MIDlet is started).
So in Java MIDlet it would be reasonable to add some small delay on start before the first ATCommand instance is created and the first command is executed. I think that to be on a safe side in production MIDlet it could be a bit more than the value I tested in this small one, let's say a few seconds.
Please test it on your side. I hope that it would be an acceptable solution for you.
Best regards,
Bartłomiej