BGS5T Exception in thread | Telit Cinterion IoT Developer Community
February 10, 2015 - 3:27pm, 10048 views
While running my midlet I get exception which isn't caught by my try-catch block but by debuger. It says:Exception in thread "Object Server Connection - Handle JMX Notification Thread" java.util.ConcurrentModificationException
Problem is that midlet sometimes runs fine for 1 hour and sometimes I get this exception in few minutes of running. Is this fault of midlet or some module settings? My scfg is:
at^scfg?
at^scfg?
^SCFG: "Call/ECC","0"
^SCFG: "Gpio/****/ASC1","std"
^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","rsv"
^SCFG: "Gpio/****/SYNC","std"
^SCFG: "GPRS/AutoAttach","enabled"
^SCFG: "Ident/Manufacturer","Cinterion"
^SCFG: "Ident/Product","BGS5"
^SCFG: "MEopMode/SoR","on"
^SCFG: "MEShutdown/Fso","0"
^SCFG: "Radio/OutputPowerReduction","4"
^SCFG: "Serial/Interface/Allocation","1","1"
^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: "Userware/Autostart","1"
^SCFG: "Userware/Autostart/Delay","600"
^SCFG: "Userware/Passwd",
^SCFG: "Userware/Stdout","null",,,,"off"
^SCFG: "Userware/Watchdog","0"
^SCFG: "Radio/Band","15"
Once I also caught SCTM_B -1 event with this:
else if(Event.indexOf("^SCTM_B") == -1)
{
sendSMS("Temperature is " + temperature + " and is reaching it's minimal limits.");
destroyApp(true);
}
Which is weird because there is no way that temperature would be at 0 C.
Hello Jure,
AT interface on external interfaces should work irrespective of the Java MIDlet.
But maybe the problem was because of the computer restart.
It would be the best to test it again to possibly find something.
Regards,
Bartłomiej
I got 2 more logs without computer restarting.
and every time it stops here:
System.out.println("getting temperature"); //this response I get
String response = sendCommand("AT^SCTM?");
System.out.println("temperature response " + response); // I no longer get anything here or after
What is interesting is that sometimes module will restart at this point and AT commands will work over USB interface.
But what is more troublesome is that sometimes module won't restart and states of GPIO's will stay at this point until you physically restart module. When this happend I connected USB interface, but I couldn’t use any of AT commands, I also tried to run program through netbeans and I got this:
Failed to set baud rate!
Communication problems to the module, check COM port and connections!
Passing control to external device emulator...
*** Error ***
Failed to connect to device 1!
Reason:
Could not connect to /192.168.244.1:55123
After I made physical reset everything worked normally.
Hello Jure,
This is interesting. Is this always the same AT command? How long the application is working before this happens? Is this command successfully executed at least once before the freeze?
Is it possible that your application is stressing the AT interface very intensively? If it does I would advice you to increase the delay between AT commands execution and check if the problem will occur again then.
Regards,
Bartłomiej
Hi Bartłomiej,
Yes since recording my logs it allways crashed here. This is inside main loop and it's called every 25-30 secconds or when an SMS or RS232 commands is send to retrive module state. So this command succesfully finishes plenty of ***** before crashing.
Application works around 24hours some***** less, some***** more. Right now is running 32hours and it still didn't crash, which is one of the longest intervals. Right now I have delay affter AT command set to 100 miliseconds. Which I think is the values that I saw in one of examples on this forum. But there is not a lot of AT commands issued inside main loop. Or is calling new Date(); also stresfull on AT commands?
Here is my AT function:
public String sendCommand(String command)
{
try
{
String answer = m_Cmd.send (command + "\r");
Thread.sleep (100); // Remember at least to implement 100 ms sleep in order to recevie any URC
return answer; //Return the AT command execution answer
}
catch (Exception e)
{
return "ERROR";
}
}
Regards
Jure
Hi,
Every 25-30 seconds does not seem too stressful.
100 ms is to prevent from sending At commands one after another to give the AT interface a chance to send URC's.
It's not much but I think that in this case it should not be important.
But to be sure and see in the logs the frequency of AT commands execution I'd add debug prints inside the sendCommand() method to print every command.
new Date() should not have anything to do with At commands.
But maybe your application is stressing the module heavily in its main loop. You can try to add some sleep() methods for test.
Please also make sure that you don't eat any exceptions - I mean that you print every exception in every catch block.
Anyhow if your application doesn't have many threads and synchronization and is not killing the AT interface it should rather not stuck on sending the command.
Regards,
Bartłomiej
Hi,
I have new update. Like I mentioned module was still running when I last posted and it worked to the Sunday. Then the program crashed, because
c.get(Calendar.DAY_OF_WEEK);
returned that there is already a new day, but when I issued
sendCommand("at+cclk?");
I got back that time is 23:59:59, so program thought that there is new day but the hour is 23 and so called wrong function which restarted program. This is not so big issue since I can just set some delay on the module when it detects new day.
But this is the longest time that program has run with this program and probably it would run on if there wouldn’t be this time issue. But there was another difference that I need to mention. When on Thursday I started the program, module couldn’t acquire time and date. So it didn’t start main loop and it waited just for SMS and RS232 commands. So I sent SMS from which it could acquire time and date and then started the main loop.
I don’t know why this would change anything, but could dallying start of the main loop help module in some way?
I will today load new program which like you suggest adds sleep method and prints out all AT commands.
Best regards
Jure
Hi,
another update. I output every AT command in the loop, and the only one is AT^SCTM. It happend today that module freezed only in 1 hour and 10 minuts at the same spot as before(temperature reading). I will now add that sleep method and see if it will be any better. But it would be better if I woulden't need to use that, because I want that GPIO outputs are trigerd in shortest time posible.
Regards
Jure
Hello Jure,
My experience is that cclk returns the same time as Calendar.
Please make sure that you don't call at+cclk? before getting time from Calendar. Or maybe you call Calendar.getInstance() to get the instance of Calendar and then you set the new time with at+cclk command and after that you don't call Calendar.getInstance() but read the time from the old instance?
I don't know what the reason for AT^SCTM? reading could be but as a workaround I'd try to reduce the frequency of temperature reading. This doesn't need to influence other application activities.
Best regards,
Bartłomiej
Hello Bartłomiej,
with help of the module supplier we opened a ticket at Gemalto and we got response that sometimes time can be 1 second behind.
Adding Thread.sleep(200) in main loop didn't help. Now I will try to remove temperature reading and will check if module still freezes and if where.
Regards,
Jure
Hello Jure,
Please try. If the application hangs on command sending it will probably not hang then.
I think that if the problem is not caused by the logic of your application which is also possible it must occur under very significant system load or only in some very rare conditions.
I've tried to issue this command in a loop with 100ms breaks for hours but everything was working fine.
Regards,
Bartłomiej