EHS6 Rebooting during AT^SISR=... when using RTS/CTS Flow Control | Telit Cinterion IoT Developer Community
June 2, 2015 - 3:38pm, 7543 views
I'm using the EHS6T to provide my product with an internet connection using 2G/3G.
Some of my customers are using the BGS2T so the driver supports this module as well (with a few minor differences during initialization)
(I'm not experiencing any problems with the BGS2T)
I'm not using any java, USB or GPIO.
Just AT commands using the serial interface with a baudrate of 115200 (AT+IPR=115200) and HW flowControl RTS/CTS (AT\Q3).
I'm waiting 200ms+ between each AT command.
I connect to a webserver using TCP.
All data communication between my device and EHS6 is polled. (No transparent mode)
(Write : AT^SISW=0,32 & Read: AT^SISR=0,256)
The device and the webserver sends data back and forth and everything seems to be fine.
But as soon as the webserver starts sending a little more data to the device the problems *****.
In the middle of the transfer I get the following behaviour:
AT^SISR=0,256
^SISR: 0,256
{´(CcvÃųXZ’êö£ƒ...[DATA]
^SYSLOADING
^SYSSTART
The EHS6 simply reboots without providing any reason.
I'm trying to send a total of 300 kB and this problem occurs every time before it completes (but at different completion percentage).
And always in the middle of a data section while reading from EHS6 as shown above.
The problem disappeared when I set up my device RTS pin wrong. Simply allowing the EHS6 to send all the time.
(My application handles retransmission of unsuccesful chunks and they all get through after a little while)
Is this a known issue or could I be doing something wrong here?
Is there a best practice to follow?
Hello,
At first glance this doesn't seem to be a known issue and it doesn't look good.
Can you check the ATI1 command to verify what firmware version you are using?
Have you tried to use bigger buffer for SISR?
Best regards,
Bartłomiej
Hi Bartłomiej,
Thanks for the fast reply.
Unfortunately my buffer size cannot be increased very much as I am working on a chip with limited ressources and a relatively large amount of functionality requirements. (My device is using STM32F103RB/STM32F103RC)
(I don't see why I would need Flow Control at all if my buffer size could cause the modem to restart but I have been testing it anyway)
Instead of changing the size of my buffer I changed my code to just read and discard any byte received while the buffer is full.This should give the same behaviour as having a buffer of infinite size (with regards to the serial communications at least).
Still reboots during read (^SISR: 0,256 [DATA]...) but it seems more stable than before.
(I could transfer around 500 kB before the error occured)
I do have other interrupts enabled in my device and expect these to cause the flow control to pause the communications in the scenario above. (which is why it still happens occasionally even though the RX buffer full is no longer causing it)
But as my device is a safety critical device first and a GPRS communicating device second it is not an option to change the interrupt priority.
I have added the version details you requested below.
ATI1
Cinterion
EHS6
REVISION 02.000
A-REVISION 00.000.15
OK
Best Regards
TS
Hello,
You have the latest firmware version for release 2.
As this problem seems serious maybe you could try updating the module to release 3.
I can send you the firmware.
Regards,
Bartłomiej
Yes sure.
That would be interesting.
I've sent you the file.
Please try if this problem still exists.
BR,
Bartłomiej
Hi Bartłomiej,
Firmware 3 seems to have solved the problem with RTS / CTS reboots.
I'm still experiencing a few problems though. It seems the module responds less quickly if it has a lot of data (from TCP) waiting to be read by my device.
Im suspecting that the buffer handling might not be as smooth as it could be, but I can work around it so not a big problem for me.
Thanks a lot for the help :)
BR TS
You're welcome!
I'm happy that the first and biggest problem is solved.
We would probably not be able to do much about that responsiveness in a short time.
Best regards,
Bartłomiej
Hello, I have EHS5-E module and got same problem.
ATI1
Cinterion
EHS5-E
REVISION 03.001
A-REVISION 00.000.14
I use the AT^SISR=0,1500 command to read data of downloaded file from FTP and after few readed data blocks (for example 1500 bytes each) i see this
^SYSLOADING
^SYSSTART
Parameters of communication like above: "... using the serial interface with a baudrate of 115200 (AT+IPR=115200) and HW flowControl RTS/CTS (AT\Q3)"
What i can try to do?
Now i simple restart downloading after module rebooting use AT^SISS=0,cmd,"get [offset]" command like i wrote in: https://iot-developer.thalesgroup.com/threads/need-example-writing-command-atsiss0cmdgetoffset
Hello,
The reboot should not happen in normal conditions. Do you have one or more modules that are behaving if that way? Is it terminal version or the bare module?
There could also be some hardware damage or failure.
The workaround is probably effective but still reboot should not happen. You could also try other baudrates and USB if possible. How are the RS lines connected?
As the previous problem seems to have been solved by the firmware update you could also try to update your module to the latest firmware release which is REVISION 03.001 A-REVISION 00.000.51.
Best regards,
Bartłomiej
To add some info,
There is a release note stating that toggling of the hardware flow control lines should not exceed 1KHz.
It looks like the hardware flow control on the EHS5 and similar modules is implemented in software.
My assumption about the modem implementation:
Banging the RTS at high rates will probably generate too much interrupt overhead to do other tasks on the modem, where the software panics and decides to reset the module, or something similar .
So, on small devices, where probably every character received results in an assert of the RTS, you can only be sure to be below 1KHz at baud rates of 9600 or lower.
That is quite dissapointing to be honest.
Pages