BGS2T RS232 flow control issue | Telit Cinterion IoT Developer Community
March 28, 2018 - 3:55pm, 6949 views
a few years ago I developed an embedded solution where my MCU communicates via the GPRS connection of a Cinterion MC55i terminal. The PPP connection is established with AT commands thrugh the RS232 interface, baud rate 115200, RTS CTS hard flow control.
Now I need to replace the modem with the newer BGS2T RS232 model but I've got some incompatibility issues. It seems to be something related to flow control because if I disable it the MCU can establish the PPP connection while if enabled it fails in handshaking phases. Maybe these terminals have different default settings so I need to adjust them to get it work with my application.
I setup the connection with the following AT commands:
Are there anyting else I should do to get it work succesfully?
This module has hardware flow control disabled by default - this is factory setting. In your initialization string there is additionally AT&F command which restores the factory settings. You can configure this with AT\Q command and read the current setting with AT&V command.
I tried but with no success :-(
I tried both to put AT\Q3 (as written in the manual) and remove my AT&F command initialization but still won't to work. I tried with my old MC55i and it works fine.
Anyway when the BGST2 is connected, the ****m chat works, it fails during ppp handshake initialization (when the ****m switch from command **** to binary ****).
Here attached following the log generated by my application (based on Rabbit TCP/IP libraries).
So it fails after configuring hardware flow control on the module and MCU while it is working fine when there is no hardware flow control set on the module and MCU. Is it still true? In case of HW flow control there is a communication possible between the module and MCU but PPP fails. Have you compared the logs for both configurations? If it was failing in both cases we would have to search for some other problem but when it succeeds with no HW flow control it looks like we should still blame serial communication. Which RS232 lines are used? Is it possible to grab PPP trace to analyze in Wireshark for example? Can you check ATI1, AT^SCFG?, AT^SGAUTH? and AT&V outputs?
Thanks for you reply, Bartłomiej.
Actually it seems not to works with both hardware and no flow control. I use RTS and CTS lines.
I have no idea how to grab PPP trace with Wireshark when the model is connected to MCU, sorry. I tried to setup a generic PPP connection on my MacBookPro with a FTDI RS232 USB adapter and the modem works perfectly. Indeed I got the init string "AT&FE0Q0V1" from the driver log.
Here attached the AT commands output taken with putty and the modem connected to my PC.
It would be the best to log serial transmission between module and the MCU both for bad case and good case, then compare. Perhaps this will show where the issue is.
There are different ways to grab the traffic. In gemalto we use an internal tool to do this, however I think apps like this should do the job:
The goal is to:
1) listen (on the PC) to serial traffic between module and MCU (if you don't have any dedicated HW for that, I think two FTDI adapters, one connected to listen serial output of the module, second to output of the MCU)
2) find the tool which will be able to present ppp in a nice way (most likely HHD will do)
I follow your suggestions, so I've installed Device Monitoring Studio on my PC equipped with 2 RS232 ports. I can see PPP packets between modem and MCU, too many packets! But I see the same things already seen so far: the MC55i works while the BGS2T it's unable to establish the PPP connection. It answers to MCU with a NO CARRIER message error. Is there a way to get more details about this generic message?
NO CARRIER is just a reaction on AT commands layer. You need to dig into PPP log to check for errors.
after looking at the log with the support of the Rabbit MCU technical team, they noticed that the Rabbit sends credentials, receives a PAP Authenticate-Ack message, sends an IPCP LCP_CONFIG_REQ packet with what appear to be reasonable values (asking for IP, primary and secondary DNS, and not proposing values). But the remote end responds with an LCP Terminate-Request.
Is there a lists of any configuration requirements that may indicate settings for the Rabbit software (or something similar for generic MCU boards)?
I think that the best way to solve this is to compare PPP negotiation for both modules (BGS2 and MC55i) and PC with BGS2.
As for list of configuration for MCU there isn't any. Generally you need to set the context with AT+CGDCONT and then use it with ATD command. I can see that you don't specify the context number in your ATD command call. According to AT specification for BGS2 in that case if no context is specified, an internal context with default properties is used. You may activate the context with AT+CGACT prior to ATD or not. You may send AT+CGATT or not. You may also configure the type of authentication for PPP with AT^SGAUTH command. By default there is PAP and CHAP setting. Additional thing to consider is that PPP implementations for MCUs are usually simplified and less flexible compared to implementations for PC.
To investiga more in depth I tried to establish a PPP connection with that modem connected to a Linux PC equipped with with a USB RS232 adapter and after some hours of debugging I discovered the right initialization script that works also in my embedded system.
At the beginning I had got the same behaviour: after the CARRIER was been detected the PPPD launched, the ****** did not finish the negotiation, returning the message log "LCP terminated by peer". After googling for this I've found the post of someone that recommended to "activate the modem" with the AT+CFUN ( https://superuser.com/questions/791780/umts-connection-fails-with-lcp-te...). Then I tried and it started to works properly.
So I've established a PPP connection through the BGS2 modem with these commands sequence:
So It seems to work only after I added the AT+CFUN=1 command. Why? Note that I've added the ATH command at the begin only to be sure that a previous connection/call is terminated.