cinterion concept reboot loop with global autostart. | Thales IoT Developer Community
November 18, 2016 - 11:09am, 4833 views
I have a midlet which works perfectly if ran via eclipse or manually started via SJAM=1. I can leave it for days with no issues.
However when I enable autostart, every minute or so, the firmware seems to restart. I have Stdout set to ACS0 and I am watching:
^SYSLOADING
SYSTEM.OUT STARTED
MIDlet:Main autostart
MIDlet:com.cinterion.jrc.JRC_Midlet autostart
repeat over and over.
There are no printed exceptions, just restarts without reason. Any idea how to fix this?
Hello,
Please try to set "Oracle-MIDlet-Autostart: 2" instead of 1 - I suppose that you have set 1. This parameter not only enables the application for autostart but also decides about the starting order. If two applications have the same value the order cannot be determined. The factory JRC MIDlet has 1 and it is advised to set at least 2 for any other custom MIDlet to make sure that the JRC MIDlet will always start first.
It seems (according to yor log) that your MIDlet starts first and I suppose that in this particular case this probably causes some problems that prevent JRC from correct initiation - maybe your app uses some features that need to be initiated by JRC for example. And if JRC is not correctly started the module is rebooted.
Regards,
Bartłomiej
I shall certainly try that, Thank you.
Unfortunaly, that didn't solve the problem. Less than a min after starting, the firmware restarted again.
I have try catch sections, which print the stack traces of caught exceptions. Sometimes, not every time, a stack trace for a caught exception is printed to stdout right before the restart. I thought only the program crashing, eg uncaught exceptions, caused a restart?
When running the program through eclipse, any uncaught exceptions are shown in output before the emulation closes. Are uncaught exceptions not generally shown on the normal stdout? Are there any logs, or is there a way to see what is going on? as said in my OP, the program does not crash when running through eclipse or when started manually. So I don't know what other investigative steps to take.
Hello,
It's getting more complicated. Please write what is your application doing. Paste some log.
Can you see "^SYSINFO: 200" or similar URC on any of the module's interfaces?
The uncaught exception should be printed. But you could also try to catch Throwable which is the master class for Exception and Error if you would like to catch everything.
The module should not always reboot after the application crashes.
How about "Oracle-MIDlet-Restart" and "Oracle-MIDlet-Restart-Count" parameters - did you set anything there? This could be one of the reasons why the module reboots. Do you use the watchdog? Please paste ATI1, AT^SJAM=4 and AT^SCFG? outputs.
When you run the program under Eclipse the execution might be slower. But there should be no difference while running the program manually and via autostart besides the autostart order issue.
Regards,
Bartłomiej
The application listens on the TX/RX COM1. When it receives data in the format of a predefined command, it executes that action. Be that send data over the internet or just an internal action. One thing to note. It is threaded. The TXRX listener is a single thread. It passes the data via a synchonised queue to a parser thread which fires each action as a separate thread, as some actions can take time.
"^SYSINFO: 200" is shown on the USB terminal interface.
"Oracle-MIDlet-Restart" is set to true and "Oracle-MIDlet-Restart-Count" is set to 2.
I do not use any watchdog methods.
ATI1 :
AT^SJAM=4:
AT^SCFG?:
Hello,
I can see in the SCFG output that "Userware/Autostart" is set to "0" - you should set it to 1, because it is the global setting for all MIDlets including the JRC which is a factory MIDlet implementing a part of the module's functionality.
SYSINFO^200 is thrown 40 seconds after system-up when the JRC midlet was not tried to start. So you should set "Userware/Autostart" is set to "1" and then try if the problem still exists.
I also see that the firmware version is quite old.
Regards,
Bartłomiej
Sorry, it is set to 0 so I can start my program manually as I am testing continious running.
It runs perfectly fine with autostart at 0 and my program started manually using SJAM
But when set to 1, allowing my program to start automatically, the described behaviour occurs.
Could it be the old firmware?
This is strange.
Please try to set "Oracle-MIDlet-Autostart" to 0 and enable the global autostart for test. Then in another test I'd enable the autostart for the MIDlet but set "Oracle-MIDlet-Restart" to false or remove the parameter form jad.
The firmware is old and it would also be a good idea to update it but I don't think that this is a source of such behaviour.
If there's many threads there could be a risk of some deadlock for example but I don't think that it could lead to the reboot.
If you would see SYSINFO^201 after enabling the autostart that would mean that the JRC MIDlet was started, but did not succeed to fully initialize. And that would cause the rebbot.
Regards,
Bartłomiej