leaving transparent mode with DTR line toggling unreliable | Thales IoT Developer Community
July 5, 2019 - 9:15am, 5246 views
Our scenario is that we enter transparent **** to a server, send some data and close transparent **** to communicate with some other host, etc. We use DTR line toggling to escape from transparent ****. Now it seems that *some****** the ****m becomes unresponsive after toggling the line. My assumption here is that the ****m either some***** stops/halts or transparent **** remains on. Any idea which? The symptom is that issueing a command such as ATI in the error case does not respond *at all*.
- Is there a guidance for how long we should keep the DTR line high?
- it seems more reliable if we toggle the DTR line multiple *****? Is this true?
Note: ATI1 gives: Cinterion||PLS8-E||REVISION 03.017||A-REVISION 01.000.05||||OK in the normal case.
some more info:
- we're using a dedicated channel, not a multiplexed channel for our transparent ****.
- this problem can happen fairly frequenctly. In our tests one-in-four transparent-exits?
- problem only occurs with downloading a large file and then trying to exit transparent ****
So you are not using multiplexer at all? Please write what hardware interface you are using and ig it's ****m or application interface.
Does the module not reply on other inetrfaces also? Did you have a possibility to try if other ways of leaving transparent **** can help in this case? Please paste AT&V and AT^SCFG? outputs.
I cannot see any timings for toggling in the documents indeed - have you alos tried different timings?
- we're using the ****m interface, the device is connected via a USB port to a microcontroller
- nope, we are not using the multiplexer at all, in transparent **** we're completely dedicated to only sending data at the moment.
- using +++ is not an option (it emits the +++ to the server which can't happen)
- using just a 2 char escape code is not an option either
- haven't tried AT&V/AT SCFG yet, however, it almost always works. It only fails once every x-th time. The config we use must therefore be okay. I'm figuring a race condition on something. Can it happen that the ****m sometimes resets RTS/CTS/etc. serial port pins (emulated over USB)? Can it happen that the ****m's firmware hangs sometimes at switching off transparent ****? Can the ****m switch back to the application interface (we've switched it to the ****m interface by sending the ****m configuration commands to do so)
I don't think module can switch back to application interface. Not sure about reseting pins emulated over USB, however, in my opinion, it cannot influence reliability of using DTR to leave the transparent ****.
I will try to check it on my side. Please let me know few more things so that I will be able to mimic your scenario:
-What IP service do you use? What is the size of data you download / upload?
-I know it happens only with large files. Have you noticed any patterns when more exactly it happens? I mean, have you noticed some connections between frequency of occuring this issue and time of how long IP service is active or how many bytes were transferred?
-How long you keep DTR line high?
-Do you have access also to USB application port or to the serial port? Can you check if you can normally send AT commands on other port when issue happens?
One more thing, I think you test it on your device, not eval board. Are you sure, issue is not related to your device? Have you verified that when issue happens, DTR line state is really changed?
we're observing this when we, in a loop do:
- receive a 983040 byte download (the size is constant for our test)
- close transparent ****
- perform an ATI1 and then *sometimes* not seeing the reply of the ATI from the ****m.
This is in our board, not the eval board, not tested yet if the emulated DTR line has changed, it was a suspicion of mine as to the cause..
- We keep the DTR high for a second.
- TCP/IP socket in transparent ****.
- upload is approx 1K http request header (also sent over same tcp socket), reply from request is 983040 bytes + a few bytes for http response header (say 256 bytes). Note: we construct our own http headers and parse the http reponse ourselves, we do not use the ****m's builtin http stack. We only use the tcp/ip functionality of the ****m.
As I understand you are using HTTP in persistent connection **** ? If not, maybe waiting for host closing the connection is an option for you ? When Host closes connection module will send "Remote peer has closed the connection" URC and will came back to AT command ****.
We are preparing test setup and scheduling the test with very similar scerario in loop:
When the results are ready we will let you know.
Indeed, I'm using a persistent connection to allow many http requests to run over the the same socket, one after the other to save on connection costs per request (socket-open can be quite expensive for our use case given that we do plenty of requests). I'd rather not add hacks such as "send a http request to let the server close the connection" though. It it helps, I can send you some logs from my test.
I figure such a test can be added to your internal nightly? testsuite at Gemalto.
Of course any log will be helpful to debug this issue. I'll wrote to you an email that you can reply to and attach logs.
If you willing to, we can also perform test using your sever to minimize diffrences between our setups.
Some more analysis I've been able to today:
- I've set it up so that APP is on USB0 and MDM on USB1. On both I see SYSSTART being echoed after ****m startup.
- I do the above described loop of SISO-SIST-download-toggle-dtr-ATI-SISC test on MDM/USB1
- once the ATI gives no reply anymore due to the issue outlined above, I issue an ATI on the APP/USB0 interface, and I get an answer!
This means that the ****m is not dead in the water. It is just not replying on MDM/USB1 anymore.
I also tried sending a +++ on USB1 instead of ATI1 but USB0 remains unresponsive.
Some more notes:
- sending a +++ on APP echos nothing and the ATI on the other USB didn't respond either
- sending a "ATI1" on the USB1/APP gives the full reply of "cinterion...lte...etc. "
- sending a SISC to try to async close the socket (where the other USB was using transparent **** on) echoed the "SISC" but didn't print "OK"
- sending a AT+CEER gave: AT+CEER|||+CEER: No cause information available||||OK|
- sending "SISO?" print SISO but no OK and no response
Could you estimate reproduction rate of this issue - how many DTR toggles it ***** to cause this issue ? Or it can happen randomly ?
In our test we can see that there was problem exiting "online" **** and it happened after over 1000 cycles (dowload file -> toggle DTR -> issue AT -> go to online **** ) but we do not confirmed if the module stop replying then.
This night we run test with 10000 sucesfull DTR toggles