TCP send buffer overflow (?) using AT interface

Legacy Open AT
1

I am using a Q2686RD connected to the UART of an AVR microcontroller (ATXMEGA128A1). I’m controlling the modem through its AT interface. Everything works fine (SMS, GPRS, HTTP downloads), except data uploads (uploading log files to an FTP server): I keep losing bytes, unless I manually insert long delays. The first several KB arrive just fine, and then the output files start showing gaping holes. The same happens if I just open a raw TCP socket and send the data.

It seems like I’m sending data on the UART too quickly. I am doing flow control (RTS/CTS), observing the modem’s CTS line and not sending until it’s clear. However, is it possible I’m overflowing the IP stack’s send buffer? If so, how do I check whether it’s safe to send more?

On the forums, I keep seeing references to the WIP_CEV_WRITE event, but I can’t find any way to get this event, or to deduce whether it’s safe to send more data, through the AT command interface. Is there a way?

Modem firmware version, etc:

AT+CGMI: WAVECOM WIRELESS CPU
AT+CGMM: MULTIBAND  900E  1800 
AT+CGMR: R73a00gg.Q2686G 2094168 032009 12:40

AT+WOPEN=2: +WOPEN: 2,"AT  v06.20","AT  v06.20"
AT+WIPCFG=3: WIP Soft v511 on Open AT OS v620
Dec 10 2008 11:49:59 WIPlib:v5a06 WIPSoft:v3a0a

For reference, this is the sequence of commands I’m sending:

AT+WOPEN=1
ATE0
AT+WIND=0
AT+CMEE=1
AT+COPS=3,2
AT+CREG=2
AT+CPIN?
AT+CNMI=2,2,0,0,0
AT+CNMI?
AT+CMGF=0
AT+CSMS=1

AT+WIPCFG=1
AT+WIPCFG=2,13,1
AT+WIPBR=1,6
AT+WIPBR=4,6,0
AT+WIPBR=3,6,15

AT+WIPCREATE=4,1,"xxx.xxx.xxx.xxx",21,"anonymous",""
AT+WIPFILE=4,1,2,"upload/log.txt"
2

Hiya,

You’re losing data inside the WIP WRITE event. Happened to me and took me ages to track it down.

There is a fixed buffer size for a TCP packet, and if your data is bigger than that then multiple packets are required for the TCP transaction. BUT … the WIP library doesn’t automatically handle splitting data - it’s up to the programmer. When using OpenAT (which you’re not at the moment), you have to take note of how much data the WIP_CEV_WRITE event consumed, and manage your own buffer.

I’m not sure how this is done in the WIPSOFT application. However, it appears that the WIPSoft library can emit CMEE errors if you turn them on using AT+CMEE=1.

First thing I would do is turn on errors using AT+CMEE=1, then see if your AT+WIPFILE command returns an error code. Errors are listed in section 6.1.7 and 10.1 of the WIPAT commands guide (I’m looking at Rev 011 for WIP 5.43).

You’re not going to get access to the WIP_CEV_WRITE event (or any others) from the WIPSOFT application - these are events that used when you’re writing your own low level © code using OpenAT and the WIP OpenAT library.

Hope this helps.

ciao, Dave

3

Hi Dave, thanks for the reply! I’ve got CMEE errors turned on, and I’m not getting anything, just “OK” after I send ETX. So worst case, there’s just nothing I can do and it’s an inherent limitation of the AT interface? That would be a pretty major issue.

4

Hiya,

Hmm, that’s not good.

Which version of WIPSoft and Firmware are you running? Just so I can make sure I’m looking at the same doco :smiley:

I have noticed that there are some options for FTP - look at the AT+WIPOPT command (options are in section 5.3.7.2 in the 5.43 doco). Depending on the type of data you’re moving, you might have to force either binary or text mode transmission.

Are you escaping the ETX character properly? Section 6.1.1.1 of the doco discusses how and when to escape the ETX (and DLE) character if either appears in your datastream.

The final thing to think about is how long after your AT+WIPFILE returns OK do you send an AT+WIPCLOSE. Don’t forget that the Q2686RD is only 2G (GPRS, max 44kBits/sec data transfer). If you are firing off an AT+WIPCLOSE immediately after you have got the OK back from the AT+WIPFILE, you may be forcing a channel close before all the data has finished being transferred. Try working out roughly how long your file upload should take, then (sleep or wait) that time after you get the OK back from AT+WIPFILE before doing AT+WIPCLOSE.

I’ve just had a quick re-read of the WIPAT guide and can’t see any command that tells you how much data is left in the buffer.

ciao, Dave

5

AT+WIPCFG=3 says:
WIP Soft v511 on Open AT OS v620
Dec 10 2008 11:49:59 WIPlib:v5a06 WIPSoft:v3a0a

It’s defaulting to binary mode, which is fine by me. I’m pretty sure I’m properly escaping ETX and DLE (by inserting a DLE in the stream before the byte-to-be-escaped).

As long as I insert long enough delays during the transfer (currently 2 ms between bytes), then everything gets through. Waiting at the end won’t be enough, I’m afraid - if I go too fast, I lose data right in the middle of the transfer, too.

6

Hiya,

This is appears to be quite old software. I would first update the firmware and load the latest version of WIPSoft. Just had a look through my installation here and there is a readme file for WIPSoft version 5.54 - which probably matches against firmware version 7.51.

Check ATI9 to see what version of firmware you’re running. Latest versions are available from the SiWi Developers Site

Yeah, you’re overrunning the internal TCP write buffer. If you’re interested, have a look at this thread [url=FTP upload indicates complete, but isn't]for a discussion of what’s going on internally.

ciao, Dave

7

Thanks, Dave.

I’ll have a look at what’s involved in upgrading the firmware. I don’t have a dev kit, just custom boards on which the modems are mounted. At least they’re not soldered on yet, so we should be able to unplug them. I don’t think the boards are set up to update the firmware in place.

However, I didn’t see anything in the change logs indicating that this issue might be fixed - is it?

8

Hiya,

No Problems.

If you’ve got a serial connection to UART1 you can do the firmware (and WIPSoft) upgrade using Hyperterminal and the AT+WDWL command without having to remove the module from the board. Your distributor should have the appropriate instructions and files to use.

Don’t know - I haven’t used WIPSoft for 4 or more years as I do app development in OpenAT (which has it’s own special set of issues!).

ciao, Dave