CC3220MOD: few questions for AT Commands usage

Hi Jo,

I'm not sure about 1 and 2. I will need to look into the code to get better understand. 

3 is a general problem with AT commands that take arbitrary data in binary format. The parser in the application looks for \r and \n as a terminator and does not account for the length of the message. I have reported this bug to R&D and a fix should be in order for the next SDK but I'm not 100% sure yet. A workaround could be to send the data in base64 but I'm not sure if this is available for all AT cmd. I will need to check this as well.

I'm also not sure about 4. I know the send command can take up to 32kb data in the argument but maybe the AT cmd interface limits this? I will als have to check the code for this.

Jesu

Hi Jo,

What SDK version and service pack is the customer using? 

1a:

Also, when they use at+accept do they always use at+socket, at+bind and at+listen before using at+accept? If the system does not return from it, it must be because the client is not connecting to it properly according to how the server socket is configured. I have never seen inconsistent behavior with the accept call. Do they always test the connection the same exact way?

1c: Check figure 6-1 in programmer's guide for recommended TCP socket flow. 

2. Could you explain the setup here? Are you referring to the interaction between the SDX55 host and the CC3220? What AT command response does the garbage data come from? 

4. How much data are they trying to send? What is the max they are doing?

Jesu

Hi Jesu,

Thanks for your help! 

They are using SDK v4.20, and I'm using v4.30.

2. I think the garbage data is the asynchronous event message. In my test on EVM I can get correct message. So this issue maybe relate to host side. Can we just disable the async event message? Is there a MACRO to disable it?

Below is customer's test result, they type in AT+T and then a mobile phone connects to it, the garbage data shows up, after that they input est as a whole command "at+test", the device returns "OK".

But in my test, as shown below, I didn't see the same thing. Compared to each other, we can speculate that garbage data should be async event msg.

4. the size of html pages and photos can be up to 100kB, and they will divide it into several 1KB segments before at+send it out.

As for \r and \n terminators thing, do you think we can release a hot fix for them shortly? My customer is in a hurry and can't wait for next release.

Here's my atcmd test procedure, please take a look and point it out if I'm doing it wrong, thank you very much!!

regards,

Jo

EDIT 4:

Hi Jo,

2. Are you asking if you can disable the response from the AT commands? I don't think this is possible as the responses are built into the AT command library. If they want they can modify the library and rebuild it but I do not recommend this as it may be a lot of work and it is not a solution it's a workaround. I would recommend whatever UART issues the customer is having on the host side. 

4. I haven't tested sending more than 1kB with at+send but the code looks like it reads the rest of the data in the residue while loop for any socket send commands:

while (residue > 0){
/* read the residue */
lRetVal = GetRawCmd((char *)&ATCommands_cmdBuffer[offset],residue);...

I'm not sure what is going on with the "&0[offset]" reference. It looks like it's not actually doing anything with the data but I have to check with a teammate tomorrow. Could you check if this while loop is getting executed when you try to send more than 1kB with at+send?

I'm not sure where I saw this &0 but I checked again on my work computer today and it's actually not &0. Anyway, it does not appear to me that the code is dividing it into segments. If the intiail GetRawCmd call exceeds the default buffer size then it enteres the while(residue) loop where it reads the rest before sending the AT cmd to the core AT command library. I think the problem is that the customer is trying to send too much data. socket send APIs are limited to roughly 31kB I believe. Do they get issues if they send 30kB of data per at+send call? 

Jesu

Hi Jesu,

*edited. 

I was asking about 3Mbps baud rate + DMA enable. I found the answers, please ignore this post.

Thanks as always,

Jo

Hi Jesu and Jo,

Thank you very much for your kind help.

Our goal is that Users can access our device's web GUI and login device via WLAN but the devices don't support WLAN.

Our solution is that use a cc3220s which work as a AP and provide WIFI for stations to access, cc3220s and the device can transfer data via uart. And cc3220s need forward data from stations to our devices, and forward the data from our devices to WIFI stations.

Now, we only use socket at command to achieve our goal without any change with cc3220s's SDK,  let me summary the problems while using cc3220s.

1.  at+accept don't work well in In blocking mode which is already under discussing.

2.  the data which need cc3220s forward to WIFI stations include '\r' and '\n', so we need use Base64 data format when call at+send.

3. When station connect and disconnect AP,  at+recv will receive garbage data which is already under discussing. After comparing with Jo's test log, I think the garbage data is Asynchronous Events report.

4. With the limit of length of at command and the data from our device's is large, the WIFI stations can not finish loading web page.To improve the transmission rate, we increase baud rate of the UART . When the baud rate is increased to 921600,  it become abnormal while  sending at command to cc3220s.

Please help solve 4 first, and if any questions, please feel free to connect me, our schedule is finish this goal this week.

Below is the log of my application.  Receive error or no response of AT+SetSockOpt.

BRs

Leanshaw Zhao

Hi Jesu, Leanshaw,

Just for record, I am not able to replicate those phenomenon from my side.

In my test I didn't see the garbage data, so I think Leanshaw can provide captured waveform for further analysis. As for baud rate other than 115200 bps, I am able to work at 1Mbps rate without problem. However 3Mbps seems too aggressive and need further optimization for handling data traffic, I would recommend Leanshaw using 1Mbps and keep the ball rolling.

As for \r\n delimiter, can we have an update on that? it seems base64 impact customer's system performance a lot, it would be great if we can fix that first. I will work with Leanshaw to fix the baud rate issue in their system.

Thanks & regards,

Jo

OK, look forward to the update! Thanks for your assistance!

Hi Jesus and Jo,

May I know when the next SDK will be release which AT+Send can transfer binary data including \r and \n ?

BRs

Leanshaw Zhao