EHS6T -JRC Issues | Telit Cinterion IoT Developer Community
February 28, 2017 - 9:28am, 7200 views
I have two EHS6T which have JRC issues:
Modem 1: With a HyperTerminal connection to the serial port, on power up I get:
^SYSLOADING
O
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”
· at^sjam=3,”a:/file.jad”,””
Modem 2:
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.
Thank you.
Bobg
Hello,
1.
"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." - that's why I was suggesting you to place the delay before initializing the ASC0 port in your MIDlet to check if the ^SYSSTART will appear then. When the port is opened by the MIDlet no URC will be displayed.
If you have configured the system out on the USB modem interface (the same that is used by the debugger) the debugger will not work. You need to change the system out to NULL or the other USB interface for example.
Or maybe the port is open in a terminal. Please close all the USB connections to the module and reboot the module.
You may also close the OJMEE Device Manager (should be visible in the system tray) if rebooting the module is not enough.
2.
So it seems that redirecting the system out to ASC1 has finally succeeded.
Regards,
Bartłomiej
Hi
1. I had previously tried adding a delay prior to initialisation of ASC0 but the modem just froze during the power-up sequence and thus assumed something else was being affected and abandoned this method. After your comment above I persevered and now I actually get ^SYSSTART on power-up. I have yet to play around with the delay required to optimise the start up process. I still don't understand why it won't work the first time I tried it.
I have rebooted the modem a number of ***** but it made no difference.
I tried closing the OJMEE Device manager but that also made no difference.
You mention closing all the USB connections - how do you propose I do that ??
I tried accessing the modem via Hyperterminal selecting the Cinterion EHSx Java Debug Modem USB opton, but Hyperterminal kept on wanting Dial-up information and thus would not allow me to connect.
2. yes stdout now redirected to ASC1, but if the problem re-appears I don't know if I have a sequence to ensure it reliably sorts itself out if it occurs again in the future, even if I follow the same sequence as before.
Hello,
1.
I just meant closing all the USB connections to the module like open terminal sessions.
If you didn't configure the system out to the debug modem interface (USB0) I suppose that this might have been the problem. When you restart the module and the USB is open in the terminal for example there may be the problem to communicate over USB after reboot. So please make sure that the USB connection is available before trying the Eclipse/Netbeans debugging. I recommended to close the OJMEE because I was suspecting that maybe something has hang behind the scenes. During the process the dialup "IP connection for remote debugging of EHSx" is started. This connection is using the "Cinterion EHSx Java Debug Modem USB". So please check if the connection is open or close. If you haven't been changing anything in the project or module configuration maybe you could try to reboot the PC.
2.
It's hard to say now where the problem was. If the module is properly configured this should be possible. Please test now if you can reconfigure it to other interfaces and back to ASC1.
Regards,
Bartłomiej