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

You are here

BGS5 - JAVA midlet on v02.000 locks up | Thales IoT Developer Community

June 20, 2018 - 12:23pm, 2092 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/****/ASC1","gpio"

^SCFG: "Gpio/****/DAI","gpio"

^SCFG: "Gpio/****/DCD0","std"

^SCFG: "Gpio/****/DSR0","std"

^SCFG: "Gpio/****/DTR0","std"

^SCFG: "Gpio/****/FSR","gpio"

^SCFG: "Gpio/****/PULSE","gpio"

^SCFG: "Gpio/****/PWM","gpio"

^SCFG: "Gpio/****/RING0","std"

^SCFG: "Gpio/****/SPI","gpio"

^SCFG: "Gpio/****/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();