CC3000 wifi example hanging after sending udp packet.

In new patch in socket.h, function simple_link_send is added part of code in the end of function : 

hci_data_send(opcode, ptr, uArgSize, len,(unsigned char*)to, tolen);

/* if (opcode == HCI_CMND_SENDTO)
SimpleLinkWaitEvent(HCI_EVNT_SENDTO, &tSocketSendEvent);
else
SimpleLinkWaitEvent(HCI_EVNT_SEND, &tSocketSendEvent);
*/
return (len);

i am commented the part with functions SimpleLink WaitEvent and work. This part of code don't exists in old patch.

So are you saying that i must remove this from the source code?

Why is it there then? For what purpose?

Is there a bug in the new patch or am i doing some thing wrong?

Hi,

Please make sure you use the basic wifi application of V1.11 with the latest patches (V1.11). Both can be downloaded from the cc3000 download site.

We have added a new event for send/sendto commands, and therefore in the basic wifi application, there are new instructions to wait for command complete.

The patches must be aligned with the basic wifi application.

Regards,

Tomer

Thanks for your response.

As far as I know i do have the latest patches...

What do i need to change for it to work? Are you saying that there is a new opt code to send a udp packet?

We have added new event. The opcode is the same, but you need to have "SimpleLinkWaitEvent"... If you don't have the following code in "simple_link_send" function, then it won't work well. In that case, download the basic wifi application from the SDK and look for the host changes in that version.

// Initiate a HCI command
hci_data_send(opcode, ptr, uArgSize, len,(unsigned char*)to, tolen);

if (opcode == HCI_CMND_SENDTO)
SimpleLinkWaitEvent(HCI_EVNT_SENDTO, &tSocketSendEvent);
else
SimpleLinkWaitEvent(HCI_EVNT_SEND, &tSocketSendEvent);

return (len);

Regards,

Tomer

Hi Tomer, i use Home Automation code, because basic WI FI code don't working samrt config using Android aplication. But that is not the discution in this post.

I use the last patch V1.11;
I use Home Automation code.
I was changed a little SDK code of Home Automation and function sendto() for UDP protocol don't work whan in code have this part:

// Initiate a HCI command
hci_data_send(opcode, ptr, uArgSize, len,(unsigned char*)to, tolen);

if (opcode == HCI_CMND_SENDTO)
SimpleLinkWaitEvent(HCI_EVNT_SENDTO, &tSocketSendEvent);
else
SimpleLinkWaitEvent(HCI_EVNT_SEND, &tSocketSendEvent);

return (len);

Im confused now.

I can only get mine to work if I comment out that code:

 Initiate a HCI command
hci_data_send(opcode, ptr, uArgSize, len,(unsigned char*)to, tolen);
/*
if (opcode == HCI_CMND_SENDTO)
SimpleLinkWaitEvent(HCI_EVNT_SENDTO, &tSocketSendEvent);
else
SimpleLinkWaitEvent(HCI_EVNT_SEND, &tSocketSendEvent);

*/

return (len);

It doesn't work if that code is in there. It just hangs after sending the udp packet. If i remove that then it seems to work. but this doesn't seem correct that i should have to remove the new additional code for it to work??

This is not the only place where you should add handling the new event.

If you're using the home automation code as part of V1.11 SDK, then it should already be integrated. In case you're not:

Have you added in hci_event_handler the following code:

case HCI_EVNT_SEND:
case HCI_EVNT_SENDTO:
{
STREAM_TO_UINT32((char *)pucReceivedParams,SL_RECEIVE_SD_OFFSET ,*(unsigned long *)pRetParams);
pRetParams = ((char *)pRetParams) + 4;
STREAM_TO_UINT32((char *)pucReceivedParams,SL_RECEIVE_NUM_BYTES_OFFSET,*(unsigned long *)pRetParams);
pRetParams = ((char *)pRetParams) + 4;

break;
}

and also in hci_unsol_event_handler:

if ((event_type == HCI_EVNT_SEND) || (event_type == HCI_EVNT_SENDTO)
|| (event_type == HCI_EVNT_WRITE))
{
char *pArg;
long status;

pArg = M_BSD_RESP_PARAMS_OFFSET(event_hdr);
STREAM_TO_UINT32(pArg, BSD_RSP_PARAMS_STATUS_OFFSET,status);

if (ERROR_SOCKET_INACTIVE == status)
{
// The only synchronous event that can come from SL device in form of
// command complete is "Command Complete" on data sent, in case SL device
// was unable to transmit
STREAM_TO_UINT8(event_hdr, HCI_EVENT_STATUS_OFFSET, tSLInformation.slTransmitDataError);
update_socket_active_status(M_BSD_RESP_PARAMS_OFFSET(event_hdr));

return (1);
}
else
return (0);
}

Can I just ask before i go about changing everything. Why do I have to add code?  Is there a bug in V1.11 wifi application?

No. 

If you're using V1.11 SDK (basic wifi application, home automation) with V1.11 patches, there shouldn't be any issue.

Is that the case? Did you download V1.11 SDK and are using it?

Regards,

Tomer

Yes I am using v1.11 basic wifi application source code. 

I downloaded the sdk  on Monday and clean installed everything. Build the source and uploaded it to the board.

Then the send opt code would send one packet and then hang. Some one above suggested that i comment out the code i mentioned above and it then worked. But some thing is still wrong if I have to be commenting out code for it to work???

Hi,

Can you please clarify which board you're using?

Please also specify the exact steps, and I will try to reproduce it at my place, as we've not encountered it before. In general, you should not change anything for it to work.

Thanks,

Toemr

Ok i am using the

MSP-EXP430FR5739

I downloaded the sdk and installed it. I then build the project in IAR and uploaded it. closed iar and reset the board. Connected it to the wifi with smart config.

I then open terminal.exe and connect to the com port at 115200.  I send it "03' (to connect to the socket) and i then send it : "040512345022710c0a8016e"

sending data 12345 to ip 192.168.1.110 on port 1000.

I have made an app that listens for udp packets on port 1000.

Once i send it the 03 i get an : DONE
then once i send the 040512345022710c0a8016e i don't get a done back (but it does send the packet) but then after that i cannot send any more codes to the board.
I cant close the socket or send another packet etc. I have to reset the board. 

But if i comment our the code is socket.c as follows:

// Initiate a HCI command
hci_data_send(opcode, ptr, uArgSize, len,(unsigned char*)to, tolen);
/*
if (opcode == HCI_CMND_SENDTO)
SimpleLinkWaitEvent(HCI_EVNT_SENDTO, &tSocketSendEvent);
else
SimpleLinkWaitEvent(HCI_EVNT_SEND, &tSocketSendEvent);
*/

return (len);

Then it seems to work fine ?

Thanks for your help

Hi,

If you want to send data 12345 to ip 102.168.1.110 on port 1000, then:

040512345022710c0a8016e is not right. You should use:

0405123450203e866a8016e

as 102->66; 168->a8; 1->01; 110->6e and port 1000->03e8.

Please clarify.

Regards,

Tomer

Was a typo in my post. it was meant to be 192.168.1.110. But as I said it was successfully sending the packet. Once it sent the packet it then hangs.

Hi,

I tried to reproduce this at my place today, but couldn't. I will try again on Sunday.

A few questions:

1. Can you use the binary file that comes with the package?

2. How can you tell the application hangs? can you wait for about 1 minute (socket inactivity timeout), and try to disconnect the connection to AP? 

3. How reliable is the application running on your remote side?

4. Have you tried this scenario on former releases and it worked?

5. Can you take air capture? I'd like to see if the packet was actually sent.

Regards,

Tomer

Hi,

I have tried to reproduce it several times today in several scenarios. In all scenarios it was working very well (to a legal address, to illegal address, to the right port, to incorrect port...).

Since you can't even see the "Done" message on the terminal screen, maybe the problem is the hyper terminal that you're using. Maybe the commands are not parsed correctly by  the host. We did encounter such terminal in the past, where each command was issued actually twice.

Please use "Tera Term" (free), and let me know the results.

Regards,

Tomer

Hi, Tomer

I met a problem similar to this.

I sent UDP data through

err=sendto(ulSocket, txBuffer, 155, 0, &serverSocketAddr,sizeof(serverSocketAddr));

and by using Wireshark I could see the UDP packets.

But after 6 packets it hung at "simple_link_send". Any idea?

What is also confusing me is that if I sent two packets in one loop,

err=sendto(ulSocket, txBuffer, 155, 0, &serverSocketAddr,sizeof(serverSocketAddr));    

sendto(ulSocket, dataPacket, 3, 0, &serverSocketAddr,sizeof(serverSocketAddr));

it is working well. Any idea?

Regards

Zheng

Hi Zheng,

The numbers of tx internal buffers in the CC3000 device is limited to 6. This means that if the device didn't get an ack, or IP address is illega/doesn't exist, then after 6 transmissions (sendto calls), there will be no free room for additional packets. Therefore, the application will be blocked in that function.

To avoid this blocking mode, you can add the following definition and compile: SEND_NON_BLOCKING (as used in HostFlowControlConsumeBuff).

BUT, in order to understand why the problem is caused, can you please provide the air capture? 

I find it hard to understand why the device will not free the internal buffers if it has already sent the UDP packets.

Would help a lot if you could also send an air capture of the two packets in a loop, to see why you don't see a problem in that scenario.

Thanks,

Tomer

Hi,

Can you please also tell which SW version are you using? is it V1.11? both patches and host driver?

Thanks,

Tomer

Hi, Tomer

Thanks for your reply. Sorry that I didn't check it on time.

I am using V1.11 and that problem was solved after cutting some codes. Maybe because of the little ram CC3000 has.

I met another problem about connecting. At first, smart config worked well and I could send udp data. But if I unplug the cc3000, turn off the router and tried to connect again at the next day(I did't touch it and just left it there), it could not connect to the router.

When I used smart config to configure the board again, it hung at smart config done but those flags (ulCC3000DHCP & ulCC3000Connected) didn't change. Even I redownloaded the original basic wifi application binary code, still samething. I can only solve it by redownloading the driver patches and firmware patches.

So it seems to me that something in firmware or driver has been changed but I don't know how it happens.

Any idea?

Thanks and regards

Zheng

2844.AirCapture.zip

Hi,

Luckily I have the backup of previous code. Hope this can help.

Thanks

Zheng

Hi Zheng,

I reviewed the logs that you shared. I couldn't see anything wrong with the UDP data being sent from the CC3000 device.

I guess the problem was indeed with the limited RAM you had in your application.

As for the second issue that you report, we have a limitation where scans will stop after 72 minutes. I will add this limitation shortly to the release notes page. 

This means that if you unplug the AP, and plug it again after 72 minutes, the device will not connect back automatically, since no probe requests packets will be transmitted after that amount of time. In general, it is not recommended to leave the device scanning for such long, as it consumes battery a lot (scan performed every 14 seconds).

We will solve this limitation in V1.11.2 version (will be in a few months from now). 

When you say, that smartconfig stops working, and that you must reprogram the EEPROM again, can you try to issue wlan_connect (manually instead) and see if it can connect in that way? 

If it doesn't, can you please send an air capture of the connection phase? In addition, can you please send network stack logs? For the network stack logs, please follow: http://processors.wiki.ti.com/index.php/CC3000_Logger

Regards,

Tomer

Hi Tomer

Thanks for your reply,

I tested with wlan_connect after the SmartConfig stopped working and it connected to AP correctly.

So I thought there were something wrong with SmartConfig probably the ram thing coz it used more than 50% of DATA ram just for encryption. I used #define CC3000_UNENCRYPTED_SMART_CONFIG to save some ram but that problem still existed. Shall I give up the SmartConfig?

By the way, I am using FR5739 and SDK 1.11.

One thing I am also confusing is that what is the relationship between firmware, driver and the code. Why the code could change something in firmware? Do they store in the same memory(FRAM)?

Thanks and regards

Zheng

Hi Zheng,

The firmware/driver code (patches) is located in the EEPROM. It has no relation to the FRAM.

The only place it does, is when using the patch programmer, which actually writes the updated patches to the EEPROM.

The driver patches are actually the network stack patches (upper layer patches), where the firmware patches are the MAC (lower level) patches.

The patches (both driver and firmware) should not be modified (and can't actually as they're write protected) once reprogrammed. Only during the patch programmer phase, where the initial step is to load without patches, the content can be modified.

Please don't stop using the smartconfig. It should work well.

I'd like to analyze your issue you're seeing. For that, can you please run the smartconfig in unencrypted mode and to an open AP (make sure to call if after delete profiles). 

Then, please run the following, and send me the content of profileArray: 

iRet = nvmem_read(2, 284, 1074, profileArray);

where:

unsigned char profileArray[284];

when smartconfig stops working (autoconnect is not done automatically to the stored profile), please run this command (iRet = nvmem_read(2, 284, 1074, profileArray);) again, and send the content as well.

Also, please do this after you try to run the smartconfig again (make sure profiles are deleted), which as you claim will be again unsuccessful. 

Last request, please provide air capture (wireshark for instance) when connection doesn't succeed. Please remember the limitation of autoconnect will not work after 72 minutes.

Thanks,

Tomer

Hi, Tomer

A simple question: I cannot define such a big array  profileArray[284], the CCS gave me a LOAD PROGRAM ERROR or sometimes gave me "Errors exists in required projects". If I commented this line, it was fine. It was weird coz I just used 300 bytes in the SRAM (DATA) 

Code Size - Text: 7954 bytes Data: 309 bytes.

Thanks,

Zheng

You should probably increase your FRAM data section. Try to define it as a global array, or decrease the other buffers, such as the tx/rx buffers. If that still doesn't work for you, please define smaller array, such as 32 bytes, and read the information in smaller chunks.

Regards,

Tomer

Hi, Tomer

This file is what I got when getting stuck in smartconfig (but only 64 bytes, I don't know how to get 284, if you need that much, I will try again), and when connect correctly, it was all 0(correct?).

When connection doesn't succeed, I cannot get anything through WIRESHARK. That makes sense to me because the cc3000 is not assigned any IP address. It stuck at 

__bis_SR_register(LPM2_bits + GIE);

Thanks and regards

Zheng

5226.test.dat

Hi Zheng,

I'm not sure I understand how to parse the data you provided. You said that you succeeded to extract only 64 bytes, but in your file I see some additional bytes, therefore, I'm not sure where to start parsing.

According to your file:

1651 9 1cfe 0 20 0
0x29C9082B
0x43826E86
0x599043AB
0x4F0123B8
0x7CB83B21
0x80CEA053
0x91CAD906
0x11809440
0x98887845
0xDF66710C
0x5B2801F8
0xAC2416A7
0x1D3B120C
0x18C898F0
0xA052153C
0x1C4693BC
0x40138DA0

What does the first line represent: 1651 9 1cfe 0 20 0? Can you tell each line to which offset it relates (assuming 1074 is offset 0)?

Also, the rest of the file contains 17 lines of 4 bytes each -> 68 bytes, but you said you captured only 64 bytes.

Please clarify.

In addition, if you're able to define an array of 64 bytes, just read the information in a loop. In that way, you would be able to send me the whole 284 bytes. This is what I meant in reading in smaller chunks.

Please send the data in all 3 cases I requested (when it succeeds, when it doesn't, after smartconfig fails..)

Thanks,

Tomer

Hi, Tomer

I made a mistake. I just copied the ram last time but did not check the iRet. Actually the iRet is always 0, which means it doesn't read anything from NVMEM_WLAN_CONFIG_FILEID. 

In the comment, it says"Err if the file can't be used, is invalid, or if the read is out of bounds." And I tried to just read one byte but still the iRet is 0, so it shouldn't be the last case.

Any idea?

Thanks

Zheng

Hi Zheng,

If you receive iRet equals 0, then it is ok. 0 means read operation was successful. 

I will correct the function's header comment in our next release to state that if successful, it should return 0, and not the number of bytes read.

Please repeat the test and send the results.

Thanks,

Tomer

Hi Tomer,

In all situation, including the error case, the return value is 0. Means that the CC3000 got those profile information but cannot connect?

The flags ulCC3000Connected and ulCC3000DHCP were 0.

Thanks,

Zheng

Yes, but I'd like to see how the profile was stored, and whether it has changed once it stopped working.

I would also like to get air capture to see if connection attempt (probe request packets) was made.

Regards,

Tomer

Hi,

The profilearray is always 0 for all cases, same as iRet.

The code of showing the profilearray is:

case UART_COMMAND_CC3000_SIMPLE_CONFIG_START:
StartSmartConfig();
for(i=0;i<5;i++)
{
iRet = nvmem_read(2, 64, 1074+i*64, profileArray);
}
break;

The air capture from wireshark is below:

4064.Aircap.zip

Thanks,

Zheng

The air capture does not reveal much, as I can't see any connection attempt. Do you have a way to capture all air transportation, as the wireshark capture you provide doesn't give that information.

Seeing the profileArray as all zeros is strange... does this happen when smartconfig succees? by succeed I mean the device will connect automatically after reset,,,

Regards,

Tomer

I did captures for two cases this time, and I can't see the connection attempt either for the failed case. 

2728.Air_cap2.zip

And for the profileArray, for both cases, all are 0 except for the NO.265 byte is 01. I don't know it is normal or not. Do you want my codes for some test?

Regards,

Zheng

Hi Zheng,

Please send me your code. I'd like to look into it. The air captures are not very helpful, as they are not really capturing all air transportation..

In any case, since you're using FR5739, I should be able to understand your problem. Please send the complete project.

btw, when using the basic wifi application (as part of the SDK that we released and tested), do you see the same issue with smartconfig?

Regards,

Tomer

Hi Tomer,

I did not test the original wifi application for that much time. It works well but I am not sure for how much time it can last.

I have emailed you the project

Thanks,

Zheng

Hi Zheng,

The project you sent contains only one source file, "sensers.c", which includes only measurement functions. Where is all the rest?

Also, I'm quite confused regarding your last statement:

"I did not test the original wifi application for that much time. It works well but I am not sure for how much time it can last."

The problem I'm after is:

"I met another problem about connecting. At first, smart config worked well and I could send udp data. But if I unplug the cc3000, turn off the router and tried to connect again at the next day(I did't touch it and just left it there), it could not connect to the router.

When I used smart config to configure the board again, it hung at smart config done but those flags (ulCC3000DHCP & ulCC3000Connected) didn't change. Even I redownloaded the original basic wifi application binary code, still samething. I can only solve it by redownloading the driver patches and firmware patches."

Can you test the same with the basic wifi application that we release as part of the package?

Please remember, as I stated already, that scans will stop after 72 minutes. This means that if you plug off the AP for such long and then power it on again, the CC3000 device will not connect automatically. Only after resetting the device, the problem will be solved. This will be solved in our next release.

Regards,

Tomer

Hi Tomer,

I just sent you the source code. 

"I did not test the original wifi application for that much time. It works well but I am not sure for how much time it can last." means that I did not test the downloaded basic wifi application for days.  I just tried the smart configuration of it and it worked. But I didn't leave it for days and to see if it will still work or not.

Now I am gonna test it but it will take some time. 

The problem is not about auto connect. Actually it doesn't connect at all even I reset it or even I download the codes again.

Thanks,

Zheng

Hi Zheng,

I believe I know where your problem is derived from. Please correct the following two in your code:

wlan_ioctl_set_scan_params(100, 100, 100, 2, 0x7FF, 80, 0, 200, iIntervalList)

wlan_ioctl_set_scan_params(ENABLE, 20, 30, 0, 0x3ff, -90, 0, 205, iIntervalList) ;

Instead of writing -80 for the RSSI you wrote 80, which means no AP will be added to the scanned list, which directly impacts connecting to a stored profile.

wlan_ioctl_set_connection_policy(DISABLE, ENABLE, ENABLE);

wlan_ioctl_set_connection_policy(DISABLE, DISABLE, ENABLE);

if you don't set the second parameter to be "DISABLE", then you actually force fast connect, which means connecting to the last AP, and not to a stored profile.

Regards,

Tomer

Hi, Tomer

You are correct, it should be -90. 

But I don't understand the second one. Even I configure the fast connection, it should connect to last AP.

And according to your comment of wlan_ioctl_set_connection_policy:

When auto is enabled, the device tries to connect according
//! the following policy:
//! 1) If fast connect is enabled and last connection is valid,
//! the device will try to connect to it without the scanning
//! procedure (fast). The last connection will be marked as
//! invalid, due to adding/removing profile.
//! 2) If profile exists, the device will try to connect it
//! (Up to seven profiles).
//! 3) If fast and profiles are not found, and open mode is
//! enabled, the device will try to connect to any AP.

which means that it will connect to stored file when I set the last parameter to ENABLE and I added profile, right?

Another question: I just found that when I used #define CC3000_UNENCRYPTED_SMART_CONFIG, the smart config did not work and stuck at smart config done. I use this to save some data ram and I only expect the smart_config working without encryption. But actually it stopped working. Any idea?

Thanks,

Zheng

It is recommended to only enable one option and not two in parallel. This should probably not be the issue you are facing, but rather the wrong RSSI value.

If you're using unencrypted mode, please make sure to remove the checkbox from the configuring application.
Please use our SDK official applications to test that.

To check how unencrypted smartconfig works, and to see the exact steps, please download the sdk, and look inside the launchpad platform - basic wifi application. Launchpad platforms are memory limited, and therefore we didn't enable encryption over there.

Please update if by changing the RSSI, the problem is resolved.

Regards,

Tomer 

Hi,

I don't think it will solve the problem. Actually the scan function has no relationship with the connecting phase in my application. In my application, the scanning part is only for scanning those AP's info, not for connection. The connecting part is at  the function of

DemoHandleUartCommand(unsigned char *usBuffer)

unless the scanning function will store the profiles automatically. Is there anyway to check the profiles?

Regards,

Zheng

Ply try. It doesn't work like that.

When you change the scan parameters, it directly affects the stored profiles as well.

When the device has a stored profile, it first scans this SSID. If the RSSI is below the threshold (as in your case), it will not try to even connect.

If not done already, Let me know the results once you perform the test.

Tomer

Hi,Tomer

Thanks very much for being so patient about the problem. I think you are right since the device worked fine in these two days. 

Best regards,

Zheng

I'm glad I could help.

Regards,

Tomer