EHS6T -JRC Issues | Telit Cinterion IoT Developer Community
February 28, 2017 - 9:28am, 7192 views
I have two EHS6T which have JRC issues:
Modem 1: With a HyperTerminal connection to the serial port, on power up I get:
The ^SYSLOADING would indicate MEM is started, but I am not getting ^SYSSTARTING thus indicating the JRC is not being loaded.
The ‘O’ is just a polling command to external equipment attached to the ASC0 port.
I have tried ‘EHSx gwinswup V03001 arn00000014 to update the Firmware, depending on flags set I get the following error messages:
· With No Autostart and No Firmware in Module : Error: cannot send update command.
· With nothing selected: Warning AT Command **** not selected.
Failed to set userware autostart **** to false.
Since there is no JRC I cannot use any AT command to interrogate the ****m, or update any settings.
The ****m is visible in Windows Explorer in Module Disk(A:) along with my MIDlet.
The ****m was previously working, and the problem appeared after stopping and removing the MIDlet o that I could update the MIDlet.
· stopping the MIDlet, at^scfg=”Userware/Autostat”,”,””,”0”
This previously also worked.
With a USB connection to the EHS6T and in Windows Explorer the ****m is visible via Module Disk (A:), and I can see previous *.jad, *.jar files.
With a HyperTerminal connection to the ASC0 com port I get no responses, ^SYSLOADING, ^SYSSTART, from the ****m on power-up, and doesn’t respond to user AT commands.
I tried to do a Firmware update on this ****m, but again on running sgwinswup I get the same error messages as for ****m 1 and thus I am unable to get an installed JRC.
I would appreciate any help in resolving the above issues with both of the ****ms.
If the JRC is not running you should also get some "^SYSINFO:" URC. You can check with AT^SJAM=5 if the JRC is running.
1. If there is the firmware on the module you don't need to check "No Firmware in Module". You should choose the modem or asc0 interface and it should work.
Please also check with AT^SJAM=4 if the JRC MIDlet is installed - as you have sent the command at^scfg=”Userware/Autostat”,”,””,”0” you have disabled the autostart for JRC also. So it might be possible that sending at^scfg=”Userware/Autostat”,”,””,"1" will solve the problem.
Other possibility is to install the JRC manually if it's not installed and also activating the autostart.
2. If you can see ^SYSLOADING and ^SYSSTART the JRC must be running on this module. If at the same time you can't send any AT command on that port this might mean that the system.out is redirected to this port. Please check on other port with AT^SCFG? command.
This now working. For whatever reason, once the user MIDlet is installed, it no longer is displaying the ^SYSSTARTING.
I was not getting a AT response due to my MIDlet running before I was entering the AT command – thus needing to enter it as soon as ^SYSLOADING had been displayed.
After the usual faffle trying to get the Remote 1 connection back, I am able to send the AT commands via a MIDlet via Netbeans 7.2 to the ****m. But still no output via HyperTerminal monitoring the serial port.
Thus I am able to send AT commands embedded within Java:
At^sjam=4, shows the JRC and my MIDlet installed.
Via the MIDlet I am able to set the Autostart to 0 or 1.
With either value I get no output via the ASC0 port
Strangely although the Autostart command appears to have been accepted, It appears to be only removing the JRC as a running MIDlet in at^sjam=5 - would have expected it to stop all MIDlets running.
Thus although the JRC is installed and running I am not getting any output via HyperTerminal on the serial ASC0 port.
I get inconsistency with the response from re-directing Stdout. Previously I appeared to be getting an OK response and at^scfg indicated it had been accepted, but now just ERROR.
Response and AT^SCFG gives the line above.
SCFG Response: AT^SCFG?
^SCFG: "Serial/USB/DDD","0","0","0409","1E2D","0058","Cinterion Wireless ***ules","EHx",""
^SJAM: "a:/JRC-1.56.30.jad","Java Remote Control MIDlet Suite","Cinterion","1.56.30",1,703294,0
^SJAM: "a:/JRC-1.56.30.jad","Java Remote Control MIDlet Suite","Cinterion","1.56.30",1
I've tried to remove the 2nd MIDlet that is installed , but not running, and no longer required via the MIDlet, but it appears to not be accepting my syntax:
The "^SYSLOADING" URC is displayed when the module boots. The "^SYSSTART" URC is displayed by the JRC MIDlet when it starts. So if for any reason it is not displayed this might suggest that JRC has not started.
But in your case I think that the reason might be different - is your MIDlet using the serial connection - maybe it opens the serial connection on the port that you use for starting the MIDlet and that is why there's no "^SYSSTART" and you cannot send any more commands.
Also when you use autostart for your application you should set at least 2 for "Oracle-MIDlet-Autostart" parameter in the jad file. This is to ****** that the JRC MIDlet will be started before your application.
When you send AT commands form inside the MIDlet you can only display the output on the System.out interface (so it might be ASC0 if you have configured it as system out with AT^SCFG command). But it's not done automatically, you need to use the println() method to print what the send() method returns. Of course it can be also sent over the serial interface that you have opened.
Changing the userware autostart parameter with AT^SCFG command does not cause that the running applications are stopped, but during the next boot all the applications enabled for autostart (all having the appropriate parameters in the jad files) will be or will not be started automatically.
To be able to use the ASC1 you need to set "Gpio/****/ASC1" to "std" and "Serial/Interface/Allocation" to "1" and restart the module. Also when you try to redirect the system out to the interface on which you are sending this command you will get ERROR.
To uninstall the MIDlet you need to use the full path that is returned by the AT^SJAM=4 command. So in this case it would be "http://192.168.244.2:2447/***2_Monitor.jad" - this is the path that was used to install the MIDlet and it has nothing to do with the MIDlet location on the module. In fact after installation the MIDlet is copied to some hidden space on the file system and it's not located in the main directory "a:/".
1: The Autostart is set to 2. I have a 6 sec delay on startup before I execute my MIDlet. Previously this seemed to be adequate and not interfere with displaying the ^SYSLOADING, ^SYSSTART URC's. This would appear to suggest there is some variation in the time that these are displayed from power-up - thus need to increase the time to accommodate this variation. It would seem that even the display of the ^SYSSTART URC message is being 'surpressed', it is not affecting the JRC functionality.
2: I now understand about using the http://.., though that gives another issue in that I would need to generate the at^sjam=4 prior to stopping / removing the MIDlet, try and separate the relevant http details since although the IP address remains the same each time the port used changes.
The at^sjam is reporting 3 MIDlets installed, and thus need to investigate separating the response for each of the MIDlets.
I am still confused on the ASC1 issue. I have configured the serial port as ASC0 - and thus after the power-up URC's being dsplayed I only expect the display of the polling commands I am sending over the ASC0 serial port. The ASC1 port is being used so that I can display any diagnostic messages via the console window within Netbeans using println - and thus should not conflict with anything my MIDlet is trying to do. Although the response from setting the command is now generating an error message, I am still getting the println commands correctly being displayed via the console window.
With the Autostart being set set to '0' it just seems strange on the subsequent 'reboot' the JRC is now not shown via at^sjam=5, but the other MIDlet that had Oracle-MIDlet-Autostart=2 is still shown as running on the subsequent reboot, as though the Userware/Autostart = 0 is only affecting the JRC and not also my MIDlet.
The delay configured with AT^SCFG command is for all applications. How do you configure this 6 seconds delay - inside your application?
Which interface are you using for the observations? I assume that ^SYSLOADING is displayed. If not and you are using the RS232 please check the AT+IPR? output. If it's 0 please change it to the value that you are using.
Is the ^SYSSTART URC displayed when your MIDlet is not installed and started automatically? Is your application using the CommConnection? On which interface?
I've got a feeling that you open ASC0 in your MIDlet and you are using ASC0 to see ^SYSSTART URC - it should rather be thrown before your app is started but have you tried to verify if it is visible on some other interface?
So you run the MIDlet from Netbeans. What interface is used for the debug connection? The debug from application will appear in Netbeans regardless of the system out port configured. Is it still not possible to set the system out to ASC1 with AT^SCFG command?
When the autostart is set to 0 with AT^SCFG command any MIDlet should be started automatically. What is the firmware version you are currently using on that module?
1. The delay is a simple sleep(6000) within my MIDlet, ie call up the comm initialisation, 6secs delay and then execute the rest of my MIDlet.
The observations are being made via HyperTerminal connected via a serial link to the ASC0 serial port.
If my MIDlet is not installed, the ^SYSLOADING, ^SYSSTART is displayed via HyperTerminal. My notes, copies of the HyperTerminal screens indicated that they were both displayed in the early days of testing, whereas with recent issues, I noticed it was not being displayed.
2. A USB connection is being used for the debug connection.
Currently I am unable to set the Stdout to ASC1 and just shows 'null. When it changed from ASC1 to null it was after playing around with initialising other settings - probably the autostart - so not an obvious reason why that should result in the current issue.
Ok, so the console output is independent of the ASC1 setting. Thus the error won't affect my current setup though it would be benificial to understand why it is not being setup correctly for other applications that use I want to use ASCI - ie for the serial output via the I/O connector.
If the console output in Netbeans is independent of ASCI this implies that with my current setup it is irrelevent, though it would be nice to understand why I can't set it if I need to use it in the future.
From ati, firmware version no. is 03.001
In debug I am getting the expected println messages on the Netbeans console window - but no polling outputs are seen via HyperTerminal connected to the console port.
So if the ^SYSSTART is displayed without your MIDlet it probably would also be visible with MIDlet on USB for example or ASC1. Have you tried?
You have written that you have added a delay in the MIDlet after the initialization of CommConnection on ASC0. So I can imagine that even though the JRC has started first your application has opened the ASC0 interface before the ^SYSSTART was thrown. To verify this you could open the ASC0 in your MIDlet after the 6s delay.
If IPR is set to 0 on ASC0 it could also cause that no URC's will be thrown until something is sent from the terminal.
Have you configured "Gpio/****/ASC1" and "Serial/Interface/Allocation" according to my advice and still are unable to set asc1 as system out? Can you set AT+CMEE=2, try again and paste the log?
If you are not seeing the messages sent by your application on ASC0 probably the terminal setting do not much the MIDlet settings. Have you changed any parameters recently? Can you paste the parameters for Connector.open()? Or maybe there's some problem with hardware connections or inside the code.
1: As indicated previously the delay to when ^SYSTART appears does not appear to be constant. I would like the keep the delay to a minimum, and not affect whether the JRC has been loaded correctly. How is the delay to appearance of ^SYSSTART determined so that any delay I add is optimised?
Still to check with different delays on whether ^SYSSTART reappears.
2: The at^scfg="Gpio/****/ASC1","std"
+CME ERROR: Unknown
Thus still not able to set ASC1 as system out.
I have another ****m that works fine, running the same MIDlet and to HyperTerminal with the same 115k2, 8N settings and using the same serial lead. Thus indicating the issue is ****m specific.
1. Have you already checked if the ^SYSSTART appears on USB interface? That would confirm my suspicions that it is not visible due to the MIDlet takes over the ASC0 interface. And if it is so the next question would be do you really need to wait for ^SYSSTART being thrown on ASC0 before the application goes on. In fact there is any maximum delay for ^SYSSTART appearance documented so that you could use this as a maximum delay.
I think that setting Oracle-MIDlet-Autostart=2 should be enough to be sure that JRC has started before your application and adding these few additional seconds should be more than enough. But to see the ^SYSSTART you need not to open the CommConnection on ASC0 before the timeout.
2. The problem with setting Userware/Stdout to asc1 is strange. I have tested on my module and there was no problem after configuring Gpio/****/ASC1 and Serial/Interface/Allocation and rebooting. It should only not work if you send the command on asc1.
Could you check once again the AT^SCFG? output for this module?
1. If I disable Autostart for my MIDlet, and reboot, I will get ^SYSSTART on the subsequent power-up, indicating it is my MIDlet 'masking' the ^SYSSTART output. Adding a delay after configuring ASC0 on power-up before I execute my MIDlet does not make any difference. This possibly suggests it may be the initialisating process for ASC0 that is resulting in 'masking' the ^SYSSTART output. The main issue I see is whether this is a concern or not. I am using a number of ****ms which appear to function fine despite no ^SYSSTART being displayed on startup.
I have not tried the USB interface on this ****m. I tried it on ****m 2 that has the issue of not displaying anything on ASC0 - but whereas previous I was able to run it under debug, now I cannot talk to it via debug or ASC0 or see any output on ASC0.
I had tried to redirect the stdout to USB - now not sure if that is what you were suggesting, but now on debug all I get is :
Connecting to module...
Failed to set baud rate!
Passing control to external device emulator...
Communication problems to the module, check COM port and connections!
*** Error ***
Failed to connect to device 1!
Could not connect to /192.168.244.1:55123
End of debug session. Emulator is closed!
Thus this seems to indicate I have now lost all communications with the module whether by USB, ASC0 or ASC1.
2. There appears to be some inconsistency in what responses I get. Although generating an error previously, the current SCFG Response for AT^SCFG indicates it has been set?
^SCFG: "Serial/USB/DDD","0","0","0409","1E2D","0058","Cinterion Wireless Modules","EHx",""