EHS6 socket stops failing after killing JRC-1.56.54.jad | Telit Cinterion IoT Developer Community
July 2, 2019 - 3:16pm, 2348 views
I have an ehs6 and I've written a program that starts a server that waits for a connection. When the connection is made, it reads data from the socket and sends it to a serial port. This works, at *****, perfectly.
Some*****, however, the program hangs on the read()-function (which is a blocking function). Data is being send to the socket from "outside", but nothing happens on the receiving end (on the ehs6-side). Only when a new connection is made to the server, the current socket is closed and the new one takes over, does the ehs6 accept new data. The next socket won't though (And the one after that will... they are alternating for some reason).
However, and this is the really weird part, if you kill JRC-1.56.54.jad on the device (with AT^SJAM=2,"JRC-1.56.54.jad",""), the program works as intended. The JRC is interfering with my program.
What does the JRC-1.56.54 program do? Do I need it? Can I prevent it from running (if I don't need it)? Is there an update that doesn't have this behaviour?
Hello,
JRC is in fact a part of the module's firmware from a functional point of view. Some of the module's functionality, especially AT commands, is implemented in JRC. Without it some AT commands may not work for example. Therefore removing it is not recommended. But it's possible - it can be uninstalled as any other MIDlet. It will also not be started automatically if you disable autostart on the module (with AT^SCFG command). But then your MIDlet will also not be started automatically. When it comes to autostart it is also recommended to set 'Oracle-MIDlet-Autostart:' in the app's jad file to a value greater than 1 because this decides about the autostart order and such a setting would ****** that JRC will always start first.
Getting back to your problem, it is very strange what you have observed. Could you also send ATI1 output to verify what firmware version you have?
There are many factors that could potentially contribute to such communicatio problems including network issues, wireless network, application bugs etc. How frequently does it happen and how long is the socket open? Are you sure that it happens when the app is in read()? Is this communication unidirectional only or bidirectional? The next socket works for a long time without any isses, another one not (from start or it hangs later?), another one works again...?
Please also make sure that you close each socket when no longer used to release resoures.
What else is the application doing when this problem occurs?
Regards,
Batrłomiej
Thanks for the response. I've rewritten part of the code (the original code was written by someone else) so I am confident that all connections opened are also closed and it appears the problem has disappeared. I'm guessing the original code didn't properly close all opened connections. I will try to inspect closer (if and when I have time to do this).
Just in case it is interesting: The result from ATI:
Cinterion
EHS6
REVISION 03.001
Alas, I spoke to soon. The connection problems have not gone away completely. I have found some puzzling behaviour though. I'm working on a simplified piece of code to show the problem, but I haven't made something yet that consistently shows the problem.
I have the following program (in pseudocode):
So the program opens up a server and start waiting for a connection. When the connection is there, the program closes the previous socket. The program kicks off the next connection handler and starts waiting for a new connection again.
The problem is that sometimes "previousSocket.close()" closes the new socket. As far as I can tell, it shouldn't. It almost behaves as if the new socket shares the memory space of the previous socket. On the other hand, if I print "socket.toString()", the socket and the previous socket have a different last part (like: com.sun.midp.io.j2me.socket.Protocol@15dc1cbe). Note that the last part does match what was printed when the socket was created (which I think means that it 'points' to the correct socket-object, but that information in the socket-object got messed up).
I hope this gives you some idea of what is going on. As said before, I will try to make a program that anyone can try that illustrates this problem. Maybe this is enough for some pointers though...
The
Hello,
thank you for your effort on this issue. Of course, please let us know if you will manage to create MIDlet that reproduce that issue.
Could you please send response to ATI1? ATI command does not provide full information about module FW - I think it would be good to check if you use the latest available FW version.
Please tell me, generally the idea is to prepare MIDlet that implements server with ability to handle multiple clients connection one after another?
Thanks,
Adam
Response to ATI1:
Cinterion
EHS6
REVISION 03.001
A-REVISION 00.000.51
The general idea is to have a server that accepts data and sends it to the serial port (and back). When a new client presents itself, the server should stop the connection to the old client if it exists (the serial port should only be used by 1 client at a time and the new one gets to be the one). In our setup only one device is connecting to this server. The only reason that a new client is presenting itself is that something went wrong in the device and it needed to create a new connection (which is why giving priority to the new client is a reasonably sane option).
Hello,
I'm sorry for late response. After performing some tests, I would suggest a bit different approach to your scenario.
I think you can avoid assigning SocketConnection objects by introducing a variable which will store information which SocketConnection object is important. The thread responsible for accepting new client will alternately use SocketConnection1 or SocketConnection2 to accept new client and open data streams from proper SocketConnection object.
I think thread responsible for accepting new connection could look like below:
That's only the idea, you will also have to take care to avoid second thread reading from data streams during changind SocketConnections object, because it can end up with exception.
Could you please share your opinion about it?
Thanks,
Adam