BGS2T - RTS/CTS Flow Control Stability | Telit Cinterion IoT Developer Community
May 22, 2019 - 3:45pm, 2846 views
Hi,
We have been using BGS2T in our products for a few years now.
Lately we started experiencing problems with modules not being able to go online.
(new modules that is - The old ones are fine)
I received one of these modules and it turns out that it stops answering in the middle of the series of AT commands I send during startup to initialize it and to open a connection.
Interestingly I found a workaround for this particular BGS2T-module.
By manually creating a pulse on my RTS-pin the module starts to communicate again as if it never stopped.
Has something been changed to the BGS2T-firmware lately?
If this is not surprising behavior to you guys I would like to know how I can identify the modules (Using AT commands) which are expected to act like this.
My baudrate is 115200
HW flowControl RTS/CTS (AT\Q3).
I'm waiting 200ms+ between each AT command.
(To be fair : For now I have just received this one module so it might be that it is not related to BGS2T firmware at all)
Best Regards
TS
Hello,
Can you state how frequently this problem happens? What device is the terminal connected to? Could you paste ATI1, AT^SCFG?, AT&V, AT+CFUN? commands replies?
Thanks,
Bartłomiej
Hi Bartłomiej,
Sure thing.
These were the results running all commands before sending any other commands to the module:
---------------------------------------------
> ATI1
>
> Cinterion
> BGS2-W
> REVISION 01.301
> A-REVISION 01.000.00
>
> OK
---------------------------------------------
> AT^SCFG?
>
> ^SCFG: "Audio/AMR","enabled"
> ^SCFG: "Audio/Loop","0"
> ^SCFG: "Call/ECC","0"
> ^SCFG: "Call/SpeechVersion1","0"
> ^SCFG: "GPRS/ATS0/withAttach","on"
> ^SCFG: "GPRS/AutoAttach","disabled"
> ^SCFG: "GPRS/RingOnIncomingData","off"
> ^SCFG: "MEop****/CregRoam","0"
> ^SCFG: "PowerSaver/****9/Timeout","20"
> ^SCFG: "Radio/Band/HandOver","0"
> ^SCFG: "Serial/Ifc","0"
> ^SCFG: "Tcp/IRT","3"
> ^SCFG: "Tcp/MR","10"
> ^SCFG: "Tcp/OT","6000"
> ^SCFG: "Tcp/WithURCs","on"
> ^SCFG: "URC/CallStatus/CIEV","restricted"
> ^SCFG: "URC/CallStatus/SLCC","verbose"
> ^SCFG: "URC/Datamode/Ringline","off"
> ^SCFG: "URC/Ringline","local"
> ^SCFG: "URC/Ringline/ActiveTime","2"
>
> OK
---------------------------------------------
> AT&V
>
> ACTIVE PROFILE:
> E1 Q0 V1 X4 &C1 &D2 &S0 \Q0
> S0:000 S3:013 S4:010 S5:008 S6:000 S7:060 S8:000 S10:002 S18:000
> +CBST: 7,0,1
> +CRLP: 61,61,78,6
> +CR: 0
> +FCLASS: 0
> +CRC: 0
> +CMGF: 0
> +CNMI: 0,0,0,0,1
> +ILRR: 0
> +IPR: 115200
> +CMEE: 0
> ^SMGO: 0,0
> +CSMS: 0,1,1,1
> ^SACM: 0,"000000","FFFFFF"
> ^SLCC: 0
> ^SCKS: 0,1
> ^SSET: 0
> +CREG: 0,5
> +CLIP: 0,2
> +CAOC: 0
> +COPS: 0,0,"Telenor DK"
> +CGSMS: 1
>
> OK
---------------------------------------------
> AT+CFUN?
>
> +CFUN: 1
>
> OK
---------------------------------------------
(There was a SIM card in the module during the tests above)
Best Regards
TS
How frequently... Every time.
I still haven't seen this module completing enough initialization commands to actually make it to opening a TCP connection. (Without the fix obviously)
The module is connected to our own PCB(STM32).
We have seen problems with flow control in the past when using EHS6 for this PCB (Details).
It might very well be that it is related to the EHS6 problem with (1KHz *** RTS) !
I just tried to force the RTS from toggling at all and that seems to remove the problem as well. ?!
Hello,
Is this the output from the new failing module? According to ATI1 it is revision 1. As far as I know there were some hardware changes in newer revisions and as a consequence it is not possible to update release 1 module to newer releases (2, 3 or 4). Please check what is the firmware version in the working modules. Currently the latest firmware for revision 1 is REVISION 01.301 A-REVISION 01.000.03. For now I can't state if this can have anything in common with EHS6 as it is the different module and I can't see any information about RTS frequency in BGS2 documentation. According to AT&V output the hardware flow control is disabled (\Q0). If you suspect RTS frequency problem, have you possibly tried to use lower baudrate for test?
Regards,
Bartłomiej
Hi,
Yes that was from the failing module.
Checking with a working module I got the following differences
ATI1:
A-REVISION 01.000.00 -> A-REVISION 01.000.03
AT&V:
+ICF: 3 (Only in the working module)
Using 9600 baud the device gets far enough with the initialization to establish a connection.
It is however not completely problem free.
It stops answering during my read command (AT^SISR=0,220)
Do you know when A-REVISION 01.000.00 was last in production?
If it is unlikely to receive them in the future it might not be that big a problem.
BR, TS
Hello,
If I understand you correctly you had previously the newer A-REVISION 01.000.03 which was working and now with the latest terminal that you have received there is an older A-REVISION 01.000.00 which is failing. Maybe the device you have bough was manufactured quite some time ago.
ICF is about character framing and 3 is a default setting and means 8 data 0 parity 1 stop bit. It is possible that the older version does not have this configurable.
I don't have such detailed data about production dates, I think that you should ask your supplier about this. You should be able to update this device to the newer firmware but it could be possibly problematic to update the whole bunch of devices.
Best regards,
Bartłomiej