July 14, 2016 - 6:36pm, 2784 views
I received this error the and I am unable to get any information regarding it. The system was working fine and then presented this error and rebooted the module.
Any ideas where this error could be coming from?
Could you write some more details - what was the application doing. Do you have a log? Has it happened only once or more *****?
Please paste ATI1 and AT^SCFG? outputs.
It has taken me some time to pin point where the problem was occuring in my code as the error only occurs once every 24 hours. I had 2 modules running the same code which shuts down the module. Before shut down there is a CALA set for boot up roughly every 5-6 after shutdown. I was only able to capture this "ASYNC" error only once however about every 24 hours the module will freeze in the same place where I first saw the "ASYNC" error.
The code in question was a method call to shutdown the module. I created a class which instanciates a single instance of ATCommand which has a synchronized method that sends "AT^SMSO" for shutting down the module. This is so multiple threads can make AT commands while only having one of the 3 interfaces used. I believe I may have had a programming error so I am re-testing to see if the problem persists. Although I found a little bit of "unhealthy code" I am not 100% convinced it is causing the error but this is speculation until the tests are complete.
Although I am testing a fix that possibly has to do with the "ASYNC" error I ran into an issue with one of the modules I was testing. The module in question boots up and I am able to run AT commands via the USB interface however I get nothing from the ASC0 interface. "AT^SPOW?" returns ^SPOW: 1,0,0. I am unable to get StdOut to work or get AT commands to run via the ASC0 interface. I would normally get a "null" during boot up in my terminal but I do not get them any longer. I have tried changing Serial/Interface/allocation and made sure power saving is off but I am still unable to get ASC0 to respond.
I even restored the system with a firmware update and AT&F. After reconfiguring everything I am still unable to communicate via ASC0.
I believe the "ASYNC" error may be related with the "dead" module because I also get a few "hardware" problems with module when the modules freezes in such a way. The amber light that indicates if the module is attached to the network stays off, AT commands do not run and the module will not enumerate the USB COM port when unplugged and replugged.
Also, twice after such a crash the module stayed unresponsive after multple reboots. Only after about the 5th reboot did the module start up normally and I was able to continue.
I am concerned about the module that seems to have the ASC0 "stuck off" which makes it unusable for me. I hope we can get it back up and running again.
I appriciate any help.
"a:/JRC-1.50.3.jad","Java Remote Control MIDlet Suite","Cinterion","1.50.3","1"
^SCFG: "Serial/USB/DDD","0","0","0409","1E2D","0059","Cinterion Wireless Modules","Cinterion BGx USB Com Port",""
If synchronization is used and the application stucks in a certain place the synchronization seems to be the fist to blame. But let's wait for test results. In case of AT commands via Java there is also an important thing - the send() method blocks until it gets the full AT command, so it waits for 'AT' string and then '\r' in the end.
According to SCFG output the ASC0 is used as system out so the AT commands will not work but I expect that you have also testes other settings. I can see that you have also activated watchdog - are you using it in your code? This may have nothing to do with your problem but do you stop watchdog before shutting down the module (I mean with Java API if you start it before)?
Could you check again the "ATI1" reply ("ATI" does not provide all details)?
I was able to run my code for 3 days without it hanging after fixing a bug I had in the code. The log still has various instances of the following 3 error messages:
aV: ctx c2 in unexpected state on termination
- aU.a(), bci=23
- eg.a(), bci=620
- com.cinterion.jrc.JRC_Context.a(), bci=86
- dT.a(), bci=130
- ok.a(), bci=7
- com.cinterion.jrc.JRC_Context.a(), bci=74
- bh.run(), bci=42
Uncaught exception: aV: ctx c2 in unexpected state on termination
- bh.run(), bci=42
ERROR - while getting native async data ...
(stack trace incomplete)
They appear in the same spot in the log, right after the shutdown command. Even with the errors the module was able to shutdown except for the very last one which gave an OutOfMemoryError which locked the module up and it did not shutdown.
I do set the watchdog on startup using the Watchdog2 class however I was not disabling it before shutdown. I have kicks where they need to be and I have tested that the watchdog works if I force the thread with the kicks to stop. I am able to send the AT command without any problems. I print a message after the command success and it never fails.
I am making adjustments so that the watchdog is disabled before shutdown. I am not calling notifyDestroyed or releasing resources like ATCommand on shutdown because I figure since the module is shutting down everything will be reset. I do close any RecordStores or files open before shutdown. I do not know if this make a difference or not however I have already made the modifications so that the watchdog is shutdown, resources like ATCommand are released and that notifyDestroyed is called.
Sorry I forgot to mention that I did try various configurations for ASC0 but I am still unable to get any output or commands to be accepted.
The error messages comes from the JRC MIDlet. As I understand they come on shutting down the module. I think that the reason could be that, as you have written, the app does not nicely stop any pending activities or does not clean any resources before. Generally you should provide releasing of resources on application exit - not doing that may cause problems in case the application is stopped and restarted without rebooting the module. I don't think that these messages were intended to be shown.
The firmware is not the latest (there is one update) but the JRC version is correct and for the newer firmware there is the same JRC version.
"Serial/Interface/Allocation" seems also correct because with every setting ASC0 should be available - but you could try to change it for test (reboot is necessary).
If your application is started automatically, please check if Oracle-MIDlet-Autostart parameter in jad file is grater than 1 just to make sure that the MIDlet will be started after JRC.
This OutOfMemoryError seems really bad, because it may mean that your application has problems with resources (it consumes too much or does not free the unused resources or is just too 'heavy' or is not optimized for small device) - these JRC errors could then probably also be the consequences of that.
So I think that you should try monitor the free memory for test and do some optimisation.
I am replying to inform you that everything seems stable now. I properly release objects and call notifyDestroyed and now I have not had any error messages, exceptions or hangs.
However I still have a module that stopped responding on the DB9 connector. I have tried all sorts of configurations for experimentation and I am not able to get the connection to work. A few ***** I was able to see ^SYSSTART after the module being completly disconnected and turned off for a while. But soon after the module stops outputting again. Once the DB9 connection stopped on the inital "native async error" I have never been able to send AT commands to this port or see anything coming from StdOut.
Just seems very strange that a bug in my software caused this. Perhaps there is a bug in the JRC or firmware and my bug exposed your bug? During inital testing I did have another module stop responding on the DB9 port after the same error however after a few reboots everything came back to normal and I am still able to use the module just fine. Maybe there is something in non-volatile memory that became currupt and the JRC is unable to restore it?
Eitherway, thank you for your help.
Thanks you for your comment. Though in this case it is really hard to judge basing only on the description. We would need to investigate the device it self, but since it is only one device so far in such state, there is no point in spending much effort, because there can be really many reasons of this. So far we did not experienced this with other projects as well.
Please keep in mind, that if you have a filling that the module is broken, you can always return it via RMA procedure.
Btw. what about stuff like power saving and hw flow controll? Are you sure thay are configured in a proper way (means power saving disabled and HW flow controll connected).
I had checked all the configuration options and really its the only one to fail in such a way. I already sent the module back via RMA procedure.
Thank you for your attention.
© 2013-2022 THALES DIS AIS Deutschland GmbH